Domain Model Leak

Nhibernate provides the best set of trade offs between the implementation complexity and the overall purity.

Domain model leak. Backend frontend communication. This doesn t work because domain layer needs to reference the specifications. Otherwise clients need to know about the nuances and intricacies of your domain which most probably makes the api hard to use.

It spreads logic too far out. 3 like 2 but make specifications part of the persistence layer. The role of entities in ddd.

Let s talk about another one of the main artifacts. Our team has a split opinion on how to model the database for this application. At the same time the onion architecture tells us that all communications should go in the backward direction only from the upper layers to the inner ones.

There still will be orm concerns leaking into your domain model however. They keep sql or object relational mapping orm constructs outside of your model. An anti corruption layer acl is another ddd pattern that encourages you to create gatekeepers that work to prevent non domain concepts from leaking into your model.

Our persistence model leaks into the domain layer making the domain layer depend on the persistence layer instead of the other way around. We should always try to express significant business concepts using classes entities or value objects. It s the job of the domain to define which contacttypes are valid for a contact.

Violation of this guideline tells us that the domain model is leaking. When using ddd the rest api should always be separated from the domain model. It often happens that a frontend application makes http calls to backend server to fetch some data.