Some Vocabulary
Problem Domain/Domain
The actual problem our software is going to solve, the purpose it is built for.
Core Domain
It’s a subset of the previous ones. It’s the essential part of the problem domain, the part which cannot be delegated and must be solved by us, software developers.
Business Logic, Business Rules, Domain Logic, Domain Knowledge, Domain Model
- The business logic you enclose in your code represents the knowledge that you as a software developer have about the problem domain.
- The business logic of an application typically resides in the two innermost layers of the onion architecture.
- We refer to the notions of those two layers as domain classes, so a domain class might be a repository, an entity, aggregate, … nut not an application service.
Main concepts of DDD
Ubiquitous Language
Bridges the gap between devs and experts.
Bounded Context
Clear boundaries between different parts of the system.
Core Domain
Focus on the most important part of the system. The problem the software is meant to solve.
Onion Architecture
- This is the architecture used at DDD, it has such name as it resembles an onion.
- Upper layers depend on lower layers but the lower layers don’t know of the upper ones.
- The core elements of our domain model should act in isolation from others.
Where does the db fit in that architecture?
- All work within the DB should be encapsulated inside the repositories.
- The code working with the data storage must be gathered under the repositories in yout domain model.
Modelling Best Practices
- Focus on the core domain first, and pay most of your attention to it.
- Start experimenting with the model (core) using unit tests (so no UI or DB needed to explore the core).
- Don’t introduce several bounded contexts upfront.
- Always look for hidden abstractions.
Entities vs Value objects
- Entities usually have an id, they are unique.
- Value objects can be treated interchangeably and have no id. They should be inmutable.
- Entities are almost always mutable.
- Entities can have identifier equality or reference equality.
- Value objects can have reference equality or structural equality.
- Value objects don’t have their own tables in the DB.
- Value objects are used by entities.
- Value objects are light.
Aggregates
An aggregate is a design model that allows us to simplify the domain model by gathering multiple entities under a single abstraction.
- An aggregate is a conceptual whole, meaning that it represents a cohesive notion of the domain model.
- Every aggregate has a set of invariants which it maintains during its lifetime. It means that in any given time an aggregate has to stay at a valid state.
- Every aggregate should have a root, and the outside world should only know about the root. So inner entities are not accessed which helps protecting its invariants.
- Aggregates also act as a single operational unit for the code in your application layer.
Bounded Context
The Bounded Context is a central pattern in the domain-driven design. Each of them is represented with their own onion diagram.
