Hexagonal Architecture, Domain Driven Design, Event Sourcing, Oh, My!

In the past weeks I've read something about Domain Driven Design and Hexagonal Architecture. And the more I've read, the more I know that I know nothing. In the end I ended up with Event Sourcing and of course, don't forget Command Query Responsibility Segragation. In this article I will give an overview of these techniques. There are also a few links, books and GitHub repositories to delve deeper into the issues.

It's a challenge to implement Domain Driven Design. You have a Service Layer in your application? Great! You put your SQL queries in a Repository? Fantastic! Your Entities know nothing about the storage system? Awesome! You also use Events? Incredible! But this is only the beginning. Now it's time to open your mind for the next level.

Disclaimer: This is only necessary for enterprise and long term projects and should help to avoid technical debt.

Hexagonal Architecture

Alistair Cockburn describes on his site Hexagonal Architecture as

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

Ok, what does it mean? It describes a timeless Design Pattern, sometimes called as Ports and Adapters. Each side of the hexagon represents an input Port e.g. HTTP (REST, SOAP, XML) which uses an adapter for the specific type. We don't care about the number of Ports, because each Adapter uses the same API to delegate the request to the application. The application is designed for specific use cases, not for the number of supported clients. Chris Fideo has written an awesome blog post about Hexagonal Architecture in PHP.

Domain Driven Design

DDD helps to write easier and better understandable/maintainable code and to achieve a high-quality software model design. DDD is all about the business, so it doe's not mean to modeling the real world. Vaughn Vernon writes in his book Implementing Domain Driven Design:

Use DDD to model a complex domain in the simplest possible way. Never use DDD to make your solution more complex.

That's not so easy as it sounds. However, it's recommended to learn more about Domain Driven Design. Have a look at these fantastic resources.

Event Sourcing

With Hexagonal Architecture and Domain Driven Design you will also find Event Sourcing which assumes an understanding of Command Query Responsibility Segragation. This is also really interesting. Event Sourcing changed the way how the data is stored. Every change of the model is only appended to the store. This results in no deletes, no database migration, fast updates and the whole change history of the model is maintained.

What's your experience with DDD and ES? Please feel free to leave a comment. Interesting is to combine Docker with CQRS and Event Sourcing. Read Introduction to Microservices and don't forget to read Microservice architecture patterns and best practices.

Discuss (0 Comments)