Documentation

Domain-driven design

There's a lot you can say about Domain-driven design (DDD). It is a concept in which the structure of the code, the team, the processes and even how we speak are focussed on the business domain (and not, for example, on the database structure, specific features or the structure of the organisation). This application focusses on the software architecture part, and largely ignores the rest.

The term Domain-driven design was coined by Erik Evans in his book (2003). I should probably add a note of thanks to Vladimir Khorikov (Enterprise Craftsmanship) for his insightful blogposts.

Design choices

Bounded contexts and aggregates

Bounded contexts and aggregates are DDD concepts that mark explicit boundaries between parts of the application, and allow you to achieve tight cohesion and loose coupling on an architectural level. For Draughts, we have three bounded contexts: Game, User and Auth, each having one or more aggregates. Read more.

Hexagonal architecture

How to separate the domain logic from the application logic. Read more.

Eventual consistency

How to handle asynchronuous event based communication with the guarantee to never lose an event. Read more.

Other topics

There are many other topics that are relevant to DDD or this application. You can read about some design principles I think are important, or about the building blocks used to implement DDD. You can read about some issues I ran into and how I solved them, what I would do differently next time or how and why I implemented the authentication.