Differences

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

--- domain_driven_design [2023/11/17 14:52] – [App architecture] skipidar
+++ domain_driven_design [2023/11/21 19:13] (current) – [DDD & Microservices] skipidar
@@ Line 7: / Line 7: @@
 == Glossary ==
-|Bounded Context |  |
+|Bounded Context |  defines the specific boundaries within which a particular model or language is valid. |
-|Ubiquitous language |  |
+|Ubiquitous language | shared, consistent language used by all team members involved in a project, ensuring clear communication and alignment between domain experts and developers. |
 |Value objects| Stores some logic from the domain. Like validation of @ in a ValueObject "Email" |
 |Entity| Will be persisted as row in a database table. Its like the JPA Entity. |
@@ Line 29: / Line 29: @@
 |Infrastructure Layer| The persistence logic. |
-== Scope Hiearchy ==
-Here is the scope hierarchy within DDD.
-<code>
-value < entity < aggregate < module < bounded context
-</code>
+==== DDD & Microservices =====
-==== DDD &  Microservices =====
+=== Overview ====
+DDD has two distinct phases.
-== Strategic Design ==
+  * Strategic
+  * Tactical
+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.|
+|Value Objects|are identified by their values. Like Address might be one. And re-created rather than copied.|
+|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?
+</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.|
-== Tactical Design ==
-  * Entities - are objects with own identifier.
-  * Value Objects - are identified by their values. Like Address might be one. And re-created rather than copied.
 {{https://learn.microsoft.com/en-us/azure/architecture/microservices/images/ddd-patterns.png}}
-  * Aggregate - 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?
+Overview of the process
+{{https://raw.githubusercontent.com/alfrepo/blog/main/content/docs/notes/article00016/ddd-process.drawio.png}}
-==== App architecture ====
+==== Single micro-service (called "app" in 12-factor app model) architecture ====
 Source: