The infrastructure layer The infrastructure layer is how the data that is initially held in domain entities (in memory) is persisted
in databases or another persistent store. An example is using Entity Framework Core code to
implement the Repository pattern classes that use a DBContext to persist data in a relational
database.
In accordance with the previously mentioned
Persistence Ignorance
and
Infrastructure Ignorance
principles, the infras
tructure layer must not “contaminate” the domain model layer. You must keep the
domain model entity classes agnostic from the infrastructure that you use to persist data (EF or any
other framework) by not taking hard dependencies on frameworks. Your domain model layer class
library should have only your domain code, just POCO entity classes implementing the heart of your
software and completely decoupled from infrastructure technologies.
Thus, your layers or class libraries and projects should ultimately depend on your domain model layer
(library), not vice versa, as shown in Figure 7-7.
Figure 7-7. Dependencies between layers in DDD Dependencies in a DDD Service, the Application layer depends on Domain and Infrastructure, and
Infrastructure depends on Dom
ain, but Domain doesn’t depend on any layer. This layer design should
be independent for each microservice. As noted earlier, you can implement the most complex
microservices following DDD patterns, while implementing simpler data-driven microservices (simple
CRUD in a single layer) in a simpler way.
199
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
Additional resources •
DevIQ. Persistence Ignorance principle https://deviq.com/persistence-ignorance/
