197
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
The domain model layer is where the business is expressed. When you implement a microservice
domain model layer in .NET, that layer is coded as a class library with the domain entities that capture
data plus behavior (methods with logic).
Following the
Persistence Ignorance
and the
Infrastructure Ignorance
principles,
this layer must
completely ignore data persistence details. These persistence tasks should be performed by the
infrastructure layer. Therefore, this layer should not take direct dependencies on the infrastructure,
which means that an important rule is that your domain model entity classes should be POCOs.
Domain entities should not have any direct dependency (like deriving from a base class) on any data
access infrastructure framework like Entity Framework or NHibernate. Ideally,
your domain entities
should not derive from or implement any type defined in any infrastructure framework.
Most modern ORM frameworks like Entity Framework Core allow this approach, so that your domain
model classes are not coupled to the infrastructure. However, having POCO entities is not always
possible when using certain NoSQL
databases and frameworks, like Actors and Reliable Collections in
Azure Service Fabric.
Even when it is important to follow the Persistence Ignorance principle for your Domain model, you
should not ignore persistence concerns. It is still important to understand the physical data model and
how it maps to your entity object model. Otherwise you can create impossible designs.
Also, this aspect does not mean you can take a model designed for a relational database and
directly
move it to a NoSQL or document-oriented database. In some entity models, the model might fit, but
usually it does not. There are still constraints that your entity
model must adhere to, based both on
the storage technology and ORM technology.
Dostları ilə paylaş: