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.
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?
Tick check! Okay, I guess that was just an itch. Oh wait! Just a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop