Introduction
Domain-driven design (DDD) is a software design approach focused on the domain. DDD isn't a software architect, so there is no right or wrong way to implement it, in my life of Software Engineering I saw this implemented in many ways with your advantages and drawbacks.
What is DDD?
DDD is a way to design software by modelling a domain from domain expert inputs, using a ubiquitous language, and dividing it into bounded contexts.
Domain-driven design is predicated on the following goals:
Placing the project's primary focus on the core domain and domain logic layer;
Basing complex designs on a model of the domain;
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Domain
A domain is a specific subject area or a business context. it's very important to model your domain very well because it's the heart of your application, if it's modelling wrong the whole software domain or that sub-domain can act differently than expected.
Ubiquitous language
It's a common language between developers and businesses/domain experts, so when we use the term A, that term can be found in the software, documentation and tickets. This is important for everyone to understand what needs to be done and avoid translation between developers and domain experts, as those translations can lead to misunderstanding the domain.
Bounded Context
When you are modelling your domain you are split responsibility, so you are defining the boundary, when you are modelling the different parts of the system it's easy to figure out who is responsible for what, the main issue lies when you need to split a domain into subdomains like you have relationships between 2 entities, who is going to responsible for keep that relationship, update or associated them.
Aggregate
An Aggregate is a cluster of domain objects (entities and value objects) that are treated as a single unit, to access that aggregate we need the aggregate root. The aggregate root is responsible for controlling access, enforcing business rules and managing the lifecycle for the aggregate.
Many developers tend to think that an aggregate is related to one table, but that isn't true all the time, especially in more complex domains, where one aggregate could be a result of a complex query.
Value Object
Value objects are objects where you don't have an identifier (ID), like Address or Phone Number.
Entity
It's the opposite of a value object, it's an object where you need an ID, like customers.
Domain Events
Domain events are events emitted by the domain or aggregate root, when there is a change or an action was performed.
Thinking about event sourcing you can use these events or publish them to a messaging gateway.
Repositories
Machanimis to get and save the aggregate root, abstracting the database.
Services
It's a way to abstract a business logic, like a behaviour or a process, it's always stateless, like HTTP requests.
Conclusion
I've shown the core concept, if you are interested, take a look at the Erican Evans DDD book and other content to have a deep knowledge. In the next article, I'm planning to show a code of DDD.
Top comments (0)