User Tools

Site Tools


domain_driven_design

This is an old revision of the document!


Domain Driven Design

Glossary
Bounded Context defines the specific boundaries within which a particular model or language is valid.
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.
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.

DDD & Microservices

Strategic Design
Tactical Design
Entities are objects with own identifier.
Value Objectsare 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?
ServicesIn 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.

Single micro-service (called "app" in 12-factor app model) architecture

domain_driven_design.1700556117.txt.gz · Last modified: by skipidar