Last week Pyxis hosted an intensive three days immersion into Greg Young's Applied DDD course. This course is amazingly packed with tips and tricks on how to come up with an architecture that delivers business value customers have come to expect from their investments in software systems. Powered by Greg’s energetic tone, this course challenged my assumptions of how software should be designed and I would recommend it to anyone interested in architecture innovations surrounding Domain Driven Design. Following is an overview of the topics we’ve tackled during the training. DDD recap
The first day was spent refreshing some of the fundamental but often misunderstood concepts of Domain Driven Design. We were reminded that Strategic Design is essential while embarking on a Domain Driven Design project as we must make sure that the value we get out from it is well worth the effort. Notions such as Bounded Contexts and Core Domain allow highly knowledgeable teams to focus on value added development work while leaving less crucial aspects of the software to others.Another topic that stroke a chord with me was Greg’s presentation of Aggregates and the role the play in well crafted software systems. Aggregates exist to provide transaction boundaries around the behaviors of domain objects. Aggregate roots provide the sole entry point to this grouping of domain behaviors and encapsulate validation logic as well as invariant consistency inside the aggregate.
CQRS
We spent the second day learning about Command Query Responsibility Segregation and Event Sourcing. CQRS is different then Command Query Separation (Bertrand Meyer) which advocates that methods that change state should be separated from functions that return value. CQRS takes the same principle and applies it to the hole architecture. In this style of design some objects (write model) represents the commands the domain respond to and other objects (read model) handles the queries and their results. Having separate models for these concerns brings a lot of benefits that I will bring up in later posts. The write model
It’s common OO knowledge that objects should be designed around behaviors in a domain. Having a dedicated write model consisting of aggregates that define transaction boundaries around the behaviors in the domain focuses work on the most valuable part of the system. This is the place to maximize the return on the work of your most skilled developers aided by domain experts.The read model
The query side doesn’t have a domain as it’s mostly straightforward boilerplate code. The preferred implementation of a read model is having request DTOs going through a thin query layer that projects directly off of a data source. This is way simpler that using the domain model to do the same. This way pre-fetched paths and optimizing ORMs queries are avoided.Event Sourcing
Event sourcing can be seen as a way to “standardize” thus reduce the cost of implementing separated read and write models. The basic idea is that all domain can be modeled as receiving commands that and producing associated events. These events can be stored as a log of what happened in the system and also be used to update the read model.
While exposing concurrency issues and ways to handle them Greg showed us a merging algorithm that’s quite simple and clever. Probably, the only piece of code Greg would ever write with a Goto statement as you can see in the picture.Fine tuning the architecture
The third day was spent analyzing the properties of this architecture and how it could be fine tuned to produce low latency, high availability and high reliability systems. Most notably CQRS architecture can used to get around CAP theorem issues which states that you can’t guarantee all three Consistency, Availability and Partitionability in one system. Look here for another treatment on how to get around CAP.All these architecture talks made me realize that using DDD and CQRS is a lot of work. And it’s no wonder that they should be applied to core domains. Now most companies I’ve worked with deal with multiple domains such as Sales, Security, Insurance, etc... And it would have been difficult to single out the one that constitutes their core domain. But every company must have a core domain otherwise it would not have a competitive advantage. Turns out a lot of companies derive their competitive advantage from their business process that integrate all of the domains they deal with. This is the place their core domain reside and that’s where Sagas help.
Pyxis source of high quality technical learning
All in all, these three days were packed with useful technical knowledge and eye opening discussions with an expert in his craft. The participants enjoyed the learning experience in Pyxis’ agile environment where they got a close up look at our facilities supporting agile teams. Pyxis is proud to have sponsored this event and is dedicated to bringing high quality technical training to the public.Other technical trainings :
