Tohuwabohu excorcism

User Tools

Site Tools

Trace:
domain_driven_design

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
domain_driven_design [2023/11/21 08:41] – [Domain Driven Design] skipidardomain_driven_design [2023/11/21 19:13] (current) – [DDD & Microservices] skipidar
Line 32: Line 32:
  
  
-==== DDD &  Microservices =====+==== DDD & Microservices =====
  
 +=== Overview ====
  
-== Strategic Design ==+DDD has two distinct phases.
  
 +  * Strategic
 +  * Tactical
  
-== Tactical Design ==+The participate in the design of micro-services as following: 
 + 
 +{{https://s3.eu-central-1.amazonaws.com/alf-digital-wiki-pics/sharex/ddd.drawio.png}} 
 + 
 +  - Start by **analyzing the business domain** to understand the application's functional requirements. The output of this step is an informal description of the domain, which can be refined into a more formal set of domain models. 
 +  - Next, **define the bounded contexts of the domain**. Each bounded context contains a domain model that represents a particular subdomain of the larger application. 
 +  - Within a bounded context, apply tactical DDD patterns to **define entities, value objects, aggregates, and domain services**. 
 +  - Use the results from the previous step to **identify the microservices** in your application. 
 + 
 + 
 +=== Strategic Design === 
 +In strategic DDD, you are defining the large-scale structure of the system. 
 + 
 +=== Tactical Design === 
 + 
 +Tactical DDD provides a set of design patterns that you can use to create the domain model. 
  
 |Entities |are objects with own identifier.|  |Entities |are objects with own identifier.| 
 |Value Objects|are identified by their values. Like Address might be one. And re-created rather than copied.| |Value Objects|are identified by their values. Like Address might be one. And re-created rather than copied.|
 |Aggregate |<wrap>  |Aggregate |<wrap> 
-The purpose of an aggregate is to model transactional invariants. Things in the real world have complex webs of relationships. \\ \\ **Example:** Customers create orders, orders contain products, products have suppliers, and so on. If the application modifies several related objects, how does it guarantee consistency? How do we keep track of invariants and enforce them?+The purpose of an aggregate is to model **transactional invariants**. Things in the real world have complex webs of relationships. \\ \\ **Example:** Customers create orders, orders contain products, products have suppliers, and so on. If the application modifies several related objects, how does it guarantee consistency? How do we keep track of invariants and enforce them?
 </wrap>| </wrap>|
 |Services|In DDD terminology, a service is an object that implements some logic without holding any state.  \\ \\ Evans distinguishes between **domain services**, which **encapsulate domain logic**, and **application services**, which provide **technical functionality**, such as user authentication or sending an SMS message. Domain services are often used to model behavior that spans multiple entities.| |Services|In DDD terminology, a service is an object that implements some logic without holding any state.  \\ \\ Evans distinguishes between **domain services**, which **encapsulate domain logic**, and **application services**, which provide **technical functionality**, such as user authentication or sending an SMS message. Domain services are often used to model behavior that spans multiple entities.|
Line 52: Line 70:
  
  
 +
 +Overview of the process
 +
 +{{https://raw.githubusercontent.com/alfrepo/blog/main/content/docs/notes/article00016/ddd-process.drawio.png}}
  
 ==== Single micro-service (called "app" in 12-factor app model) architecture ==== ==== Single micro-service (called "app" in 12-factor app model) architecture ====
domain_driven_design.1700556117.txt.gz · Last modified: by skipidar