domain_driven_design
This is an old revision of the document!
Table of Contents
Domain Driven Design
A good overview: http://www.methodsandtools.com/archive/archive.php?id=97
Glossary
Bounded Context | |
Ubiquitous language | |
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. |
Modules (packages or namespaces) | Way to implement conceptual contours. Helps to separate areas of domain. |
Aggregate Root | https://martinfowler.com/bliki/DDD_Aggregate.html. a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items. PlayList. Clinic Visits. |
A repository | is an abstraction over the persistence store |
services | In Services we implement cross cutting functionality. |
Domain services | Implement communication between different entities, which is not directly associated with one concrete entity. E.g. Transaction from one account to another. Domain service can both call or be called by a domain entity |
Application services | Application services use domain services, but not vice versa. Application layer service handle cross cutting concerns: security, packaging requests, receiving requests. |
Layered Systems
DDD is mainly about the Domain Layer. THe whole logic should be implemented in this layer. But DDD expects the other layers to exist.
Presentaion Layer | UI. The presentation layer generally deals with serializable representations of a domain object |
Application Layer | Holds the security logic, request packaging, unpackaging. |
Domain Layer | The Domain logic. |
Infrastructure Layer | The persistence logic. |
Scope Hiearchy
Here is the scope hierarchy within DDD.
value < entity < aggregate < module < bounded context
DDD & Microservices
Strategic Design
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.
- 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?
App architecture
domain_driven_design.1700231788.txt.gz · Last modified: by skipidar