Lessons Learned Applying DDD, CQRS and Event Sourcing

This article is part of the Developer Developer Developer 13 series covering all the talks I visited on 23rd June 2018 and what I learned.

The final session I attended was Neil Barnwell’s talk on Lessons Learned applying DDD, CQRS and Event Sourcing.

Starting with Domain Driven Design, he said this is overkill for developing a simple Create Read Update Delete (CRUD) system, and that there was nothing wrong with simple CRUD systems.

When using Domain Driven Design:

• The problem domain should drive the design.
• Know your boundaries — consistency and transactions
• Crack down on Ubiquitous Language
• Consider values which are independently volatile

CQRS stands for Command/Query Responsibility Segregation.

Neil said that maybe people are afraid of it because it is considered too complex, but the basic idea is actually very simple and the implementations of it can also be simple.

Neil defined Event Sourcing as “An aggregate’s current state is a function of it’s events.”

He said don’t worry about the performance too much because if the boundaries are right it will work.

Then he moved on to Event Stream Storage Options, discussing RavenDB, EventStore and regular SQL.

He said there are training issues to be mindful of when introducing any new technologies to a company.

He recommended Guids generally, but said they are horrible for versioning.

Then he summarized the talk with four points:

He said the number of fallacies of distributed computing have gone up from 8 to 11 and we should learn them all.

You can contact Neil directly if you have questions or are interested in working for ByBox: