Edition 0 Updated to asp. Net core 0

Oren Eini. Infrastructure Ignorance
https://ayende.com/blog/3137/infrastructure-ignorance
 
•
Angel Lopez. Layered Architecture In Domain-Driven Design
https://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/
 
Design a microservice domain model 
Define one rich domain model for each business microservice or Bounded Context.
Your goal is to create a single cohesive domain model for each business microservice or Bounded 
Context (BC). Keep in mind, however, that a BC or business microservice could sometimes be 
composed of several physical services that share a single domain model. The domain model must 
capture the rules, behavior, business language, and constraints of the single Bounded Context or 
business microservice that it represents. 
The Domain Entity pattern 
Entities represent domain objects and are primarily defined by their identity, continuity, and 
persistence over time, and not only by the attri
butes that comprise them. As Eric Evans says, “an 
object primarily defined by its identity is called an Entity.” Entities are very important in the domain 
model, since they are the base for a model. Therefore, you should identify and design them carefully. 
An entity’s identity can cross multiple microservices or Bounded Contexts.
The same identity (that is, the same 
Id
value, although perhaps not the same domain entity) can be 
modeled across multiple Bounded Contexts or microservices. However, that does not imply that the 
same entity, with the same attributes and logic would be implemented in multiple Bounded Contexts. 
Instead, entities in each Bounded Context limit their attributes and behaviors to those required in that 
Bounded Context’s domain.
For instan
ce, the buyer entity might have most of a person’s attributes that are defined in the user 
entity in the profile or identity microservice, including the identity. But the buyer entity in the ordering 
microservice might have fewer attributes, because only certain buyer data is related to the order 
process. The context of each microservice or Bounded Context impacts its domain model. 
Domain entities must implement behavior in addition to implementing data attributes.
A domain entity in DDD must implement the domain logic or behavior related to the entity data (the 
object accessed in memory). For example, as part of an order entity class you must have business logic 
and operations implemented as methods for tasks such as adding an order item, data validation, and 
total calculation. The entity’s methods take care of the invariants and rules of the entity instead of 
having those rules spread across the application layer. 

---

200 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
Figure 7-8 shows a domain entity that implements not only data attributes but operations or methods 
with related domain logic. 
Figure 7-8. Example of a domain entity design implementing data plus behavior 
A domain model entity implements behaviors through methods, that is, it’s not an “anemic” model. Of 
course, sometimes you can have entities that do not implement any logic as part of the entity class. 
This can happen in child entities within an aggregate if the child entity does not have any special logic 
because most of the logic is defined in the aggregate root. If you have a complex microservice that 
has logic implemented in the service classes instead of in the domain entities, you could be falling 
into the anemic domain model, explained in the following section.