I am trying to learn domain-driven design (DDD). And I don't understand how to construct domain model from the persistence store. I am making my domain models without public setters in order to keep my states safe and consistent, but ,on the other hand, to construct them from persistence store I need to have those setters. In "Implementing DDD", it is possible as long as I use ORM tools. But what if I don't want to use ORM, actually I want to use NoSQL. I might use Event Sourcing. If you guys have any better suggestions. What is the best practice in this situation.
How to construct domain model from persistence store? #DDD
805 Views Asked by Uuganbold Tsegmed AtThere are 3 best solutions below
On
I believe you are mixing domain models with data transfer objects (DTO). Repository does not use (reference) domain models, it uses DTOs.
Normally you would pass IRepository instance to ctor of business model object, and then model itself can use repository to get the data (in form of DTOs), set its private properties directly, or use its methods to validate data, if required by business. You pass IRepository instance because you would probably need to save data also, not just load it. So, in order for business object to be able to know how to persist validated data, it needs reference to repository instance.
Or, if you want to be really pure about this, and not passing the repository instance, and leave loading / saving to the application layer, then you would call repository.Getxxx somewhere in application layer and pass data (as DTOs) to business model ctor.
On
How to construct domain model from the persistence store?
My advice: if your domain is a bit complex, don't do that.
A DB model is a model designed in order to store data. If you generate your domain model from this, the result will be an anemic model: entities without any behavior.
A domain model designed with DDD principles in mind will result in a rich model made of entities and value objects with behaviors. Those behaviors will help you to achieve the use cases that belongs to a particular bounded context.
That being said, if your bounded context is CRUD only with no domain complexity, this is a totally valid approach. Remember that DDD does not force any architecture choice. You have plenty of tactical patterns that you might want to use or not depending on your bounded context complexity.
First of all it doesn't matter what database you use, so you can use an SQL database or a NoSQL, the same applies for ORM or a low level client.
What your repository needs to do is collect the data and pass it to the constructor of your domain models, so the public setters are not necessary. I'm adding some pseudocode with a simple example: