194
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
https://learn.microsoft.com/archive/msdn-magazine/2016/may/data-points-dapper-entity-
framework-and-hybrid-apps
•
ASP.NET Core Web API Help Pages using Swagger
https://learn.microsoft.com/aspnet/core/tutorials/web-api-help-pages-using-
swagger?tabs=visual-studio
•
Create record types
https://learn.microsoft.com/dotnet/csharp/whats-new/tutorials/records
Design a DDD-oriented microservice
Domain-driven design (DDD) advocates modeling based on the reality of business
as relevant to your
use cases. In the context of building applications, DDD talks about problems as domains.
It describes
independent problem areas as Bounded Contexts (each Bounded Context correlates to a
microservice), and emphasizes a common language to talk about these problems. It also suggests
many technical concepts and patterns, like domain entities with rich models (no
anemic-domain
model
),
value objects, aggregates, and aggregate root (or root entity) rules to support the internal
implementation. This section introduces the design and implementation of those internal patterns.
Sometimes these DDD technical rules and patterns are perceived as obstacles
that have a steep
learning curve for implementing DDD approaches. But the important part is not the patterns
themselves, but organizing the code so it is aligned to the business problems, and using the same
business terms (ubiquitous language).
In addition, DDD approaches should be applied only if you are
implementing complex microservices with significant business rules.
Simpler responsibilities, like a
CRUD service, can be managed with simpler approaches.
Where to draw the boundaries is the key task when designing and defining a microservice. DDD
patterns help you understand the complexity in the domain. For the domain model
for each Bounded
Context, you identify and define the entities, value objects, and aggregates that model your domain.
You build and refine a domain model that is contained within a boundary that defines your context.
And that is explicit in the form of a microservice. The components within
those boundaries end up
being your microservices, although in some cases a BC or business microservices can be composed of
several physical services. DDD is about boundaries and so are microservices.
Dostları ilə paylaş: