Domain Driven Design and DAO
From Giews
- DAO
An architecture with DAO's is implicitly mapping the domain model to the database within the DAO. In such an architecture there is not an explicit and independent domain model but a set of value objects (vo) or data transfer objects (dto).
Practical implications: The persistence layer needs to be implemented by the developers.
Advantages: More control over the database and therefore performance. More in line with the current software engineering approach.
- DDD
Working with an explicit and independent domain model makes it possible to use a persistence framework like Ibatis or Hibernate for the mapping. In an architecture with a domain model mapped to the database there less DAO's, they are implemented and therefore hided by the framework. The domain model is used to generate the database schema and the mapping files. The domain model is the reference of the concepts of the application, not the database schema.
Practical implications: The persistence layer needs to be performance tuned after the generation. This option is implies a knowledge investment in the OR mapper like Ibatis of Hibernate.
Advantages: Having a explicit and independendant domain model is a effective method to manage complexity of the application. The application will be less complex and there is less work on the persistence layer.
- Decission
DDD There where the OR mapper is not performant, manual performance tuning will be done.
- Argumentation
No need to write a lot of persistence code. A transparent way to manage the complexity of the application. The domain model can be tested with unittests (Junit) and with tests (also Junit) which reflects the Usecases. Having a fully tested domain model will decrease the time needed for bugfixing.
