DDD-Digression

Eric Evans wrote an excellent book on Domain-Driven Design, a book which I evangelize at every opportunity. There’s also a fairly active discussion group. At my last job I was able to apply DDD concepts in a Java/Spring/Hibernate project.

Rather than being an exhaustive catalogue of design patterns, the book describes a few which, used together, form an architectural blueprint I find very appealing. There are the usual Value Objects and Entities, but DDD distinguishes certain entities as aggregate roots, entities which need to be globally accessible (eg. by query) rather than navigated to via other entities. You can extend a UML class diagram by drawing a line around aggregate boundaries and identifying any roots.

Then for persistence, there is the notion of a repository, a collection-like API which is considered part of the domain layer, and applies to aggregate roots rather than to all entities. A repository would have methods for adding, removing or finding entities which are determined by the design to be aggregate roots. Developers sometimes question the repository notion, finding it indistinguishable from a Data Access Object, or DAO. Although repository methods are often simple pass-throughs to a DAO, I believe that one distinction is validation and other business logic that wouldn’t be appropriate in a DAO, which can be thought of as part of the infrastructure rather than the domain. For example, UserRepository.addUser(User user) might throw a DuplicateUserException. I’d use generic DAOs or drop the DAO implementation detail before I dropped the repository abstraction. With the automatic persistence of “dirty” object graphs in an ORM like Hibernate, this pattern works very cleanly. When creating new aggregates, persist the root by adding it to the repository, and let the ORM take care of the rest. Note the absence of methods called “save”.

I’m not sure yet whether DDD has much applicability to the client side of RIAs, but I find it to be a helpful tool in designing object models, including persistence.