x screenshot

Domain-driven design

The hexagonal architecture

Domain-driven design (DDD) is a concept to focus development on the business domain. It has opinions on the structure of the code, the team, the processes and even the language to use.
To teach myself (and others) about DDD, I made a demo web application about the board game draughts. You can find it on GitHub.

DDD's take on software architecture

DDD wants us to split our application in two ways, based on two questions: What are we talking about and how are we going to do it.

For the first part we split our application in bounded contexts and each of those we split in aggregates. Bounded contexts are parts of the application that operate separately and can only talk to other contexts with event based communication. In the most extreme case, each bounded context becomes a microservice. Aggregates are parts of the domain model that update as a unit.
Once we've divided our application by subject of responsibility, we know what we are talking about in general (the context) and which parts specifically (the aggregates).

Bounded contexts: Game User Auth
Aggregates: Game, GameState,
AuthUser, Role,
The structure of the Draughts domain divided in bounded contexts and their aggregates.

For the second part we split our application based on type using the hexagonal architecture pattern. This splits the tasks at hand in several layers, where parts in each layer are only allowed to talk to parts in the same layer or deeper.
For a web application this typically means that we need to parse HTTP requests, interact with a database and perform some sort of business logic. You do not want a database query to worry about HTTP requests, or your business logic to rely on database queries. Hence, domain objects (which are responsible for your business logic) are in deeper layers than your repositories (who execute your queries), and controllers (which handle the requests) are on the outside. It's customary to use a service as a middleman if multiple repository or domain model calls are connected, but they can be skipped.

Hexagonal architecture
The layers of the hexagonal architecture in a web application.

Example: win a game

Let's look at what happends when a player makes the final move and wins the game. To process this move, we need to access three aggregates across two bounded contexts. In the game context we first get some information from the game aggregate and then edit the gamestate aggregate to make the move. We raise an event to notifiy the user context. In there we pick up the event and update the statistics.

The flow for the final move
The flow through the application for the final move.