DDD (Domain Driven Design)
Last updated
SC - Software Architecture
Last updated
It is a way to develop software focusing at the heart of the application - called Domain- with the objective of understanding its rules, processes and complexities, and separating them from other complex topics that usually are added during development.
It is about modeling a Ubiquitous Language in an explicitly Bounded Context.
DDD is/should be used for complex softwares.
Big projects have many areas, many business rules, many people with different visions in different contexts.
A lot of the complexity from this softwares are not technological, but communicational, from separating contexts, understanding of the business from many angles.
The challenge is to balance the amount of needed information to preserve the invariance and the resource consumption (like memory), since the seggregation of Domains and Subdomains can increase the amount of code and memory usage.
DDD always breaks down into two sections:
Tactical Modeling, helps on building the Domain Model, separating your Core/Domain entities into Domain Objects, complementing Clean Architecture Entity Layer.
Strategic Modeling, to help divide your application code into separate code bases, depending on Domains and Subdomains.
That are used for different reasons, together or separated.
Helps understanding the deepness of the Domain and Subdomains of the application.
Think of the meaning of the word Client for different areas of the business. They could have different meanings and refer to different things.
So having everyone speak the same language is indispensable.
Helps showing what is business complexities and what is technical complexities.
The interaction between bounded contexts is by a Context Map.
The integration patterns naturally define the relationship type between each bounded context.
Shared Kernel
Collection of code that can be shared like a npm package. It will be used by multiple bounded contexts.
Using code versioning like Semantic Versioning 1.0.0.
Customer/Supplier
You have the Upstream (The consumed) and Downstream (Who consumes).
There is a supply relationship where the customer and the supplier may determine how the contract between them should be.
Conformist
The downstream must accept what the upstream gives him.
Brings the risk of accepting the nomenclature of the upstream into your code.
Usually requires an Anti-Corruption layer.
Anti-Corruption Layer
Is a layer to translate nomenclatures that come from upstreams.
Like when conforming.
Open-host Service
When you offer services to the outside.
You try to simplify the internal complex logic, by providing the simpler interface for the outside world.
Helps in having a universal language (Ubiquitous Language) between everyone involved. (From the software specification until the variables names used in the code)
Helps creating a strategic design using .
