Edition 0 Updated to asp. Net core 0

Additional resources 
•
Dapper
https://github.com/StackExchange/dapper-dot-net
 
•
Julie Lerman. Data Points - Dapper, Entity Framework and Hybrid Apps (MSDN magazine 
article)

---

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.