Home
The boilerplate follows an architecture inspired by Domain Driven Design and Clean Architecture. It implies in some patterns and methodologies having to be followed to ensure the separation of concerns and make the codebase more maintainable and designed for flexible architecture.
- separate core business logic from implementation details
- be independent of any database, framework or service
- use simple pure functions whenever possible
- make the project easy to scale “horizontally”
- make the project easy to test
- use type system primarily to communicate the “ubiquitous language” of the core domain
Long story short, a better way to think about event storage is this:
There are multiple event lists (event streams) and each one contains events that correspond to a different aggregate
Even though “action causes reaction” statement is correct, it doesn’t really tell you much on how a command is created, captured or validated, how invariants (business rules) are ensured or how to deal with coupling and separation of concerns.
For this to explain it’s useful to be aware of the “big picture” upfront:
But with so many components in the system, it can be difficult to “see the forest for the trees”.
This architecture divides the software into layers using a simple rule: outer layers can depend on lower layers, but no code in the lower layer can depend on any code in the outer layer.
- At the heart of the architecture is a domain model (containing business rules), implemented using only pure functions (easy to test)
- Command handlers can use a domain model and communicate with the outside world only by using injected repository which implements repository interface (easy to mock)
- The outermost layer has access to all inner layers. It provides the implementation of repository interfaces, entrypoints to the system (REST API), connection to the database (Event store) and similar.