module granularity

[kato Kwong]

Hi Kirk,

Having a look around your website I see you discuss the granularity of modules and I guess this is discussed in the book.

I'm keen on domain driven design, where domain objects reside in the same packages as the factories and repositories that create and store them.

This means the application data access layer is not as a whole in a single explicit package.

Do you think that this is wrong and that domain entities should be separated from domain repositories (and DAOs), even to the extent of shifting them into separate modules?

Cheers,

Kato

[Kirk Knoernschild]

Hello,

Granularity is discussed at several points throughout the book. There is a section dedicated to Granularity in Chapter 5.

If your domain objects contain behavior (ex. business rules) and your DAOs contain data access code, then they should be separated. There are at least a couple of different reasons. First, it ensures physical separation in addition to logical separation. Second, you give yourself the opportunity to reuse each.

There are several different ways I've seen DAOs implemented. In some cases, the DAOs create the domain objects. I consider that bad. In other cases, the DAOs get the data and returns a simple DataBean (aka. Transfer Object) to the domain object. I consider this better. In the most flexible case, a DAOFactory assembles all of this stuff together for us (the DAO, DataBean, and Domain Object). That gives us much more flexibility in how we ultimately get the domain object. For instance, it means a domain object could be built several different ways using different SQL statements.

Since we don't typically create factory classes anymore, and instead use Spring, all of this would be assembled using a configuration file and you'll wire it all together at runtime. The remaining issue is that Spring config files are global. If you change any of the classes, you have to find the right config file and change that too. This is where OSGi and Spring DM can be pretty neat. You can encapsulate the factory within the module itself. Take a look at the end of Chapter 3 (excerpt link below) to see this in action. I think you'll find it quite interesting.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk

[kato Kwong]

Hi Kirk,

Thanks, that excerpt is quite interesting – may have to buy the book

But I just have a few follow up points that perhaps you can help me with.

I’m using JPA and so my entities contain JPA annotations. Then my DAO implementations simply use the entity manager. So do you think this separation is still valid?

If so and I create different module JARs, can we put them in packages of the same name? I believe this is not allowed in OSGi because the packages will shadow each other, is this right?

In keeping with the domain driven approach, I have entity repositories that often use DAO interfaces, but are a domain concept – not a software one. My business logic involves the use of repositories to retrieve entities, update and save them. Would these become the service layer in a new module that encapsulated the data access logic?

Cheers,
Kato