Domain Driven Design Distilled by Vaughn Vernon

Share This Post

Table of Contents

We are big fans of DDD and we were lucky enough to assist an event held by Magento, with Vaughn Vernon as a key speaker, presenting his latest book: “Domain Driven Design Distilled”. I bet you can imagine how exciting it is to share the room with someone that recognised in the programming community, specially when you get a few hours off of work because of that.

You are probably already familiar with Vernon’s work, because of the ‘red book’: Implementing Domain-Driven Design, one of the most influential pieces of work of the last decade. If not, I strongly recommend it to any person that is impatient to learn about Domain Driven Design.

The main topic of the meeting was the implementation of microservices with Scala and Akka. One complex matter, which I won’t try to tackle in a single article, instead, I do want to share some insights of Vernon on the industry of software architecture that I found interesting:

Domain Driven Design Distilled

Industry of Extremes

The first statement that draw my attention was that we live in an Industry of Extremes. To illustrate this situation, Vernon used the Single Responsibility Principle as an example. SRP says that a class should have only one responsibility inside the functionality of our software, which is encapsulated in that class. Or, as Robert C. Martin describes it:

“A class should have only one reason to change.”

Yet, it’s not easy to draw red lines between what we call responsibilities to separate them, which gives room to discussions, and therefore, allows us to fall into extremes. Another similar situation happens with data consistency.

Transactional Outbox Pattern Benefits

Transactionally or Eventually Consistent

To achieve Transactional consistency in database transactions we have the ACID set of principles:

If one part of the transaction fails, the database state remains unchanged (Atomicity).
The database state can only change from one valid state to another valid state. All existing constraints and triggers should be respected (Consistency).
System is immune against concurrent use. Concurrent transactions never access incomplete data changes (Isolation).
Data is always persisted once the transaction is finished (Durability).

Nevertheless, transactional consistency is not always needed. And it is not a programmer’s responsibility to decide if it is or not. To have the answer to this question, it is necessary to ask the business itself, therefore, to ask the Domain expert.

Monolith or Microservice

Falling in the extreme of pursuing the transactional consistency usually ends up in a Monolith system which is too often pushed to a verge of becoming a ‘Big Ball of Mud’, where Domain models exist in one big messy place.

Nevertheless, MSA permits to avoid this situation. But to create actual Microservices the are several rules of thumb to be applied. Otherwise, the result will be what Vernon called Distributed Monolith.

One Microservice should cover one Bounded Context.
A Microservice should own a separate database, to store all events in an Event Journal.
A Microservice coupling with the system must remain always low.

At last, if any of the described above ended up interesting to you, don’t hesitate to read more about this topic from Vernon himself; you can easily find some of his code samples. I would say trial and error is the best way to learn, so don’t be afraid of “standing on the shoulders of giants”, and give it a try.

Notes on Domain-Driven Design Europe II - 2018 edition

I know I’ve mentioned it earlier, but I would like to say it one last time, I really do recommend you read Domain Driven Design Distilled by Vaughn Vernon, you won’t regret it.