Datalayer Decisions (Repository, DAO, Services) in Domain-Driven-Design Applications
I have been working several applications lately at work that use Domain-Driven Design
I had a couple of questions about design choices I saw made in the applications I’m working with. I recently talked to an architect who uses DDD a lot (Model first), and had the chance to pick his brain. Here’s what I came up with. I’d be curious to hear other opinions via comments:
1. Why choose Repository vs DAO pattern or vice-versa? I even found some Spring posts recommending both.
Answer: Repository fits nicely on a legacy schema. If you’re domain objects do not match the database, then there this pattern works better. For green field, DAO choice means you can simplify mapping, because your schema is under your control.
One additional consideration: DAO model first means that your database may not be normalized and / or friendly for reporting tools etc. If you are in an enterprise setting, that reporting should be done off of a separate schema anyway (data warehouse). The warehouse records can be written in the service layer (see question 2) or extracted via an ETL process batch job. If this is overkill, then you may want to use Repository and map to a friendlier schema.
In the case of using both repository and DAO, this seems to be of value when you are not using an ORM. The DAO simply manages CRUD for one table, and the Repitory layer handles joining and translating entities into domain objects.
2. What is the purpose of a service layer that encapsulates a DAO or Repository?
Answer: There are various concerns that relate to the application, but not the domain model. For example, a Product model will have validation that is true in and of itself. For example, it must have a name, and that name is 50 characters or less. But in the context of an order, there may be additional validation rules that involve various domain models in the context.
So the service layer should provide a single interface for various actions related to domain that the User Interface layer should call. So for instance, a web application has an admin section where I want to delete a product. And a product can only be deleted without orders.
Top to bottom, the stack looks like the following:
- Web application: Sends request to Product Service to delete a product
- Product Service:
- Calls OrderRepository to validate there are no related orders
- Calls ProductRepository to delete Product
That is rather simple logic in the service, but why should the product repository know about the order repository? These services serve as single endpoints for user interface programmers. They can simply request a product deletion and handle appropriate validation messages / errors. They don’t care about context validation, model validation, and all the sub steps involved, that is handled for them.
And each class follows the single responsibility rule.
