DDD/CQRS/EVENTS Flashcards
What is DDD?
It’s a way of designing and implementing software that aims to reduce complexity by focusing on the business domain and connecting the implementation to the domain, resulting in expressive and flexible solutions.
The canonical text is Eric Evans’ Domain Driven Design.
What is the fundamental part of DDD?
Doing DDD does not require any particular framework, language, architecture etc. In particular, you can do DDD without CQRS, event sourcing, etc.
The fundamental part of DDD is the focus on the domain, which translates into the UBIQUITOUS LANGUAGE - the core terms and expressions of the domain that should be reflected in the software itself. The process of discovering the ubiquitous language itself results in a better understanding of the domain.
How does DDD differ from the Clean Architecture?
DDD is not tied to any particular architecture. The core architectural part of DDD is a rich domain model, meaning entities (classes) that are rich in behaviour and closely reflect the real word business problem.
The main focus of clean architecture is having a core layer which should not depend on any external framework, service etc. In clean architecture, dependencies should point inwards. And this is true also of typical DDD architectures, where the rich domain model is at the core of the architecture and should not have any dependencies on infrastructure concerns etc.
In DDD what is the domain model
The domain model is the set of entities and value objects that make up the domain and are at the core of the architecture. The entities should not just be data, but should be rich in behaviour. They should encapsulate the business logic. True OOP.
In DDD what are domain services
Domain services are part of the domain model and are responsible for any behaviour that does not fit into a single entity (aggregate) (e.g. behaviour that must span more than one entity).
In DDD what are application services
Application services interact directly with the domain model, and the rest of the application interacts with the application services. The app services are responsible for coordinating the behaviour of the domain model entities and domain services. The app services are the clients of the domain model.
In DDD what are persistence and infrastructure layers?
The layers responsible for persistence and infrastructure e.g. web, caching, external services etc.
In DDD what is an aggregate?
A DDD aggregate is a cluster of domain objects that can be treated as a single unit. It is the logical boundary for things that can change in the business transaction of a given context.
It can be made up of one or several entities. In case of several, then one of them is the aggregate root, which interacts with the outside world and contains the others.
Aggregates should be saved as one and retrieved as one.
The root ensures the integrity of the whole aggregate.
In DDD what is an Entity vs a Value Object
Entities have distinct identities. Two entities that have the same properties are still distinct things.
A value object (think a Money class) does not have a distinct identity. If 2 Money types have the same property (e.g. amount and currency), they are considered equivalent. Value objects should be immutable.
What is CQRS?
Command Query Responsibility Segregation. Essentially splitting up your architecture into a command side and a query side. Commands change data. Queries never change data, only retrieve it.
By splitting them up, you can have have different data access patterns - e.g. the query side can use straight SQL while the command side uses an ORM.
This can also simplify your domain model as it can be used only for the command side (the query side does not really need a rich domain model as it is basically just querying data from the DB).
Describe more or less how CQRS/”command pattern” works
AKA this kind of thing https://blogs.cuttingedge.it/steven/posts/2011/meanwhile-on-the-command-side-of-my-architecture/
Each feature is either a command or a query. A command or a query are objects that encapsulate the data that makes up the command or query.
Controllers will accept data and translate this into a command or query. This will be passed to a command handler which handles the command or query, calling upon domain model entities or services to do the work.
This is great for decoupling your application. Every feature is implemented in a single command or query and respective handler and there is very little coupling between functionality. Reuse of code can be done but prudently; duplication is OK if it means that things remain decoupled. The main thing here is SRP - single responsibility principle.
What is event sourcing?
With event sourcing every action taken within a system is an event that is stored in an event store. So instead of storing the current state of data, you store each event. To get to the current state you basically replay the events from the store.
In DDD what is bounded context?
todo
What is the specification pattern?
Encapsulating domain rules in classes that can be reused. E.g. they encapsulate an expression like:
thing => thing.age >= 18
How do you avoid CRUD based thinking?
More logic and behaviour in models. Encapsulation is key.
