title: DDD: Where to put persistence logic, and when to use ORM mapping
body: <p>We are taking a long, hard look at our (Java) web application patterns. In the past, we've suffered from an overly anaemic object model and overly procedural separation between controllers, services and DAOs, with simple value objects (basically just bags of data) travelling between them. We've used declarative (XML) managed ORM (Hibernate) for persistence. All entity management has taken place in DAOs.</p>
  
  <p>In trying to move to a richer domain model, we find ourselves struggling with how best to design the persistence layer. I've spent a lot of time reading and thinking about Domain Driven Design patterns. However, I'd like some advice.</p>
  
  <p>First, the things I'm more confident about:</p>
  
  <ul>
  <li><p>We'll have "thin" controllers at the front that deal only with HTTP and HTML - processing forms, validation, UI logic.</p></li>
  <li><p>We'll have a layer of stateless business logic services that implements common algorithms or logic, unaware of the UI, but very much aware of (and delegating to) the domain model.</p></li>
  <li><p>We'll have a richer domain model which contains state, relationships, and logic inherent to the objects in that domain model.</p></li>
  </ul>
  
  <p>The question comes around persistence. Previously, our services would be injected (via Spring) with DAOs, and would use DAO methods like find() and save() to perform persistence. However, a richer domain model would seem to imply that objects should know how to save and delete themselves, and perhaps that higher level services should know how to locate (query for) domain objects.</p>
  
  <p>Here, a few questions and uncertainties arise:</p>
  
  <ul>
  <li><p>Do we want to inject DAOs into domain objects, so that they can do "this.someDao.save(this)" in a save() method? This is a little awkward since domain objects are not singletons, so we'll need factories or post-construction setting of DAOs. When loading entities from a database, this gets messy. I know Spring AOP can be used for this, but I couldn't get it to work (using Play! framework, another line of experimentation) and it seems quite messy and magical.</p></li>
  <li><p>Do we instead keep DAOs (repositories?) completely separate, on par with stateless  business logic services? This can make some sense, but it means that if "save" or "delete" are inherent operations of a domain object, the domain object can't express those.</p></li>
  <li><p>Do we just dispense with DAOs entirely and use JPA to let entities manage themselves.</p></li>
  </ul>
  
  <p>Herein lies the next subtlety: It's quite convenient to map entities using JPA. The Play! framework gives us a nice entity base class, too, with operations like save() and delete(). However, this means that our domain model entities are quite closely tied to the database structure, and we are passing objects around with a large amount of persistence logic, perhaps all the way up to the view layer. If nothing else, this will make the domain model less re-usable in other contexts.</p>
  
  <p>If we want to avoid this, then we'd need some kind of mapping DAO - either using simple JDBC (or at least Spring's JdbcTemplate), or using a parallel hierarchy of database entities and "business" entities, with DAOs forever copying information from one hierarchy to another.</p>
  
  <p>What is the appropriate design choice here?</p>
  
  <p>Martin</p>