Lessons learned when applying DDD CQRS


Marco Franssen /

4 min read689 words

Cover Image for Lessons learned when applying DDD CQRS

While I was trying to apply DDD in combination with CQRS I learned myself some good lessons.

I was trying to apply this in an agile approach, using the project method SCRUM. I started the project by translating all use-cases to smaller user stories. Based on this user stories I defined a first sprint.

In the first sprint I didn't had or make a design for the complete domain. So I wasn't completely sure if I made the right decision for the 'aggregate root / bounded contexts' needed for the first sprint. In the second sprint I figured out it wasn't the right choice so the second sprint took a lot of refactoring work. So I didn't made it to the new userstories / functionality.

1. So the first lesson I learned was. Before you start applying DDD you have to identify at least the bounded contexts of your domain and define your aggregate roots. This will save you a lot of refactoring work. Last but not least it gives you a good overview of the complete project.

When I defined by bounded context I figured out I put some responsibilities on the wrong AR when I started to implement my designs. The lessons I learned here are.

2. Just tell, don't ask. This will lower the complexity and dependencies in your design. So use a domain service to tell one AR what he needs to know about another AR to make his decisions.

3. In these domain services you can use your readmodels to validate. This helps you to keep complexity low. So don't hesitate to give up some consistency when the consistency isn't a big deal.

To keep complexity low I forced myself to keep properties out of my implementation. So first question that came up to me was. How can I check if something has the right conditions when I can't access them through properties. The solution was simple.

4. Just use a Guard method on the object who can make decisions and pass the dependencies to the method. When all conditions are ok just do nothing, when they don't just throw an exception.

5. Avoiding properties will help you placing the logic in the right place, and prevents you from making some kind of 'God'  object / class.

Last but not least I figured out dependency injection is the key to keep dependencies as low as possible. in order to unit-test you domain scenario's. Because I write my unit-tests on commands and testing the resulting events, I rarely have to rewrite test when refactoring things in my  domain. The only component that could be dependent on this are my CommandExecutors. These CommandExecutors are injected into the framework as well as in my production environment as in my test environment.

So after a few weeks of applying DDD and CQRS I already became a better architect, just by changing my mindset. I'm very impressed about the results I made to keep the code such simple for solving the, in first place, complex issues I was encountering.

By the way, I'm using the ncqrs framework. You can get a stable enough version from my fork at Github. However the framework is still far from perfect it saves you a lot of work. Everything that doesn't fit can however be changed because the source code is opensource and it is really fun to participate and share thoughts about how it should be improved. So don't hesitate to use this kind of framework, because the real issues you can only encounter when applying it in a real project. I think this is the only way to trace the points of pain and improve these kind of frameworks.

Hope you enjoyed this post. All feedback and additions are welcome, because learning never ends. Last but not least I would like to thank the people who helped me to change my mindset.

You have disabled cookies. To leave me a comment please allow cookies at functionality level.

More Stories

Cover Image for Knockout that cascading dropdown

Knockout that cascading dropdown


Marco Franssen /

In this article I will explain how you can make cascading dropdowns with Knockout.js. Knockout.js is a JavaScript library which provides you some stuff to implement the MVVM pattern.  Knockout provides you the following stuff: Declarative bindings: (Easily associate DOM elements with model data using a concise, readable syntax); Automatic UI Refresh: (When your data model's state changes, your UI updates automatically) Dependency tracking: (Implicitly set up chains of relationships between mo…

Cover Image for Pitfall in FakeItEasy

Pitfall in FakeItEasy


Marco Franssen /

The current project I'm doing is a CQRS based project, using the ncqrs framework. Today I came to a phase I needed some mocking done for some of my domain services. I choose FakeItEasy to handle this for me. So I started by just adding a reference to my DomainScenario project using a Nuget package. For some of my complexer scenario's I ran into some issues which took me about about 45 minutes to fix one of my tests. For fixing all other failing tests I had to do the same trick. Before I explai…

Cover Image for Injecting dependencies in MVC3 with Windsor

Injecting dependencies in MVC3 with Windsor


Marco Franssen /

In this blog post I will explain how to inject your dependencies into your controllers in a MVC 3 application with Castle Windsor. First of all you need to create a WindsorInstaller. This class is responsible for the configuration of your IoC container. In the above class the first line registers all your controllers with lifestyle configured to Transient. Depending on the lifestyle you choose Windsor will clean all resources. Other lifestyles are Singleton, Pooled, PerWebRequest, PerThread. T…

Cover Image for Some notes on the DDD/CQRS Course

Some notes on the DDD/CQRS Course


Marco Franssen /

In this blog post I work out some of the notes I made in Greg Young’s DDD/CQRS course in Krakow Poland. In Domain Driven Design there are some important things to think about. In DDD we make a difference in the following components. Aggregate Roots Entities Value Objects An Aggregate root is a set of multiple things that belong to each other. The aggregate should have a name that describes the whole. To come to a domain driven design you should take the following steps: Denormalization T…