Edition 0 Updated to asp. Net core 0

Ordering.Domain
layer library has 
dependencies only on the .NET libraries or NuGet packages, but not on any other custom library, such 
as data library or persistence library. 
Figure 7-6. Layers implemented as libraries allow better control of dependencies between layers 
The domain model layer 
Eric Evans’s excellent book 
Domain Driven Design
 says the following about the domain model layer 
and the application layer. 
Domain Model Layer
: Responsible for representing concepts of the business, information about the 
business situation, and business rules. State that reflects the business situation is controlled and used 
here, even though the technical details of storing it are delegated to the infrastructure. This layer is 
the heart of business software. 

---

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.