CQRS + Event Sourcing – Step by Step

A common issue I see is understanding the flow of commands, events and queries within a typical CQRS ES based system. The following post is designed to clear up what happens at each step. Hopefully, this will help you to reason about your code and what each part does.
Continue reading

Are You Making These 10 DDD Mistakes?

Making mistakes is part of programming. Spotting them early can save you time. I’ve started to notice a common set of ‘DDD Mistakes’ which many of us seem to make. And yes, I’ve made them all at some point in my career. This is by no means the definitive list – I’m sure there are more.

1. Allowing Persistence and Databases to Influence your Models

This is a common ‘mistake’ when following a DDD approach. Many of the tactical patterns like, Aggregate Roots, exist to simplify your models.  They achieve simplicity by isolating your solution from infrastructure concerns like databases. The real starting point of a DDD approach is always the domain experts. If you find yourself starting with a schema or data model, alarm bells should be ringing. Your final solution may end up using stored procs over a relational model. But a database should have no part of the early stages of modelling.

2 – Not Immersing Yourself With Domain Experts.

At the heart of Domain Modeling is the desire to bridge the communications gap. The better you understand the problem domain, the better your solution. Now when I say understand the problem I mean from the perspective of the domain expert.  So if you are modeling a circuit board testing system, spend time with the electronics engineers. If it is an aircraft refueling coordination system, spend time with the re-fueling coordinators (or whatever they are called).

3 – Ignoring the Language of the Domain Experts.

A key concept in DDD is something called the Ubiquitous Language. The idea is simple. First understand the language of the experts. Then infuse the language of the domain experts into all your code and discussions. Right down to the method, class and variable names.

Health Warning: The Ubiquitous Language is only ubiquitous within a bounded context. For example, the word ‘Client’ may have a different meaning in the accounts BC to the warehouse BC.

4 – Not Identifying Bounded Contexts

How do you solve a complex problem? A common approach is to break it down into smaller parts. Isolating and solving smaller problems make resolving the bigger ones more likely. This is one of the key benefits of a bounded context. Identifying them has a direct impact on the likelihood of building a successful solution.

5 – Maintaining Bounded Contexts Despite Deeper Domain Insights

When you have a found a context which seems to work, it’s tempting to stick with it. But this rigidity can become a problem. The process of domain discovery evolves over time. Your code should evolve with those discoveries. To do this, your code needs to be supple. You need to cover your code in the right kind of tests. This gives you the freedom to rework your code to reflect those discoveries. It allows you to take advantage of your growing understanding of the domain.

6 – Using Anemic Domain Models

This is a common symptom of a modelling process gone wrong. It is also a sign you are not doing ‘DDD’. But what is an anaemic domain model? It is domain classes full of public properties with getters and setters. They are classes with no behaviour of their own. These have become prevalent due to ORM’s mapping database schema’s to code. You may still have these kinds of classes in your system but they are not your domain objects. Rather look to encapsulate objects and provide behaviour.

7 – Assuming All Logic is Domain Logic

Again this is a common error. The assumption is that all logic is domain logic. You can tie yourself in knots trying to shoehorn everything into your domain models. The most obvious example is field validation on forms. Most field validation logic should live close to the client code. In a web application, it would be in the javascript and endpoint controller. For example, validating an email, or a required first name field. The confusion arises because we attempt to keep all validation logic in one place.  For example, we may check an age is in a particular range. This is field validation. Whereas ensuring a person is old enough to handle hazardous material, this is a domain concern. Other types of ‘logic’ may also not be best suited within a domain object. An example of this is a when an aggregate exists solely to house a process which should involve many aggregates. A better approach could be to use a process manager. This would handle the processing logic. While the aggregate processes the implementation logic.

8 – Over Using Interaction Tests

It is important to keep your code supple. This is particularly true at the early stages. But to allow for major re-factors you need a safety net. This net is a good suite of tests. They should be a help to the development process rather than a trip hazard. I’ve noticed interaction tests have a tendency to hinder re-factors. This is because interaction testing expects certain methods to have been called. It ensures these methods are called with particular parameters etc. Here’s the problem. If we change how the work is done but not the end result, the tests will fail. A much more robust mechanism of testing is by checking the final state. Given a certain scenario, when a specific input is received, a specific final state is expected. Key here is the test doesn’t care how that state was arrived at. This frees you to monkey with the innards and be confident the system still behaves correctly.

9 – Treating Security as Part of the Domain (unless it actually is)

Security is an important part of a lot of the systems we build today. Rarely, however, is it part of the domain. The result of a calculation of risk, doesn’t change if calculated by a superuser or not. So while security is an important part of the system, it shouldn’t play a part in the modelling of the domain. Unless it is actually part of the domain!

10 – Focusing on Infrastructure

I’ve already mentioned the common mistake of focusing on the database at the start. Another mistake is to focus on infrastructure concerns at the modelling stage. An example of this could be taking a data feed from a device. You should define the shape of the data for your system. Then use adapters to ensure whatever service feeds you data, is transformed into the correct format.

If all that wasn’t enough, here is a bonus one…

BONUS: 11 – Skipping the EventStorming Process

EventStorming is often overlooked by developers. It involves a different kind of skill set. It can be hard to get the right people in the room. And there are no guarantees you will come up with something useful. The reason I’ve added it is it is something well worth doing. If you want to speed up the design process. If you want the best chance of spotting those ‘seems’ in the domain as early as possible. If you want to get buy in. If you want involvement. Both crucial elements of a successful project. Then don’t miss out the EventStorm.

Health Warning: It may be DDD is not the right approach for the system you are building. In which case the advice above would not necessarily apply.

Making mistakes is part of programming. Spotting them early can save you time. I’ve started to notice a common set of ‘DDD Mistakes’ which many of us seem to make. And yes, I’ve made them all at some point in my career. This is by no means the definitive list – I’m sure there are more.Continue reading

Download this infographic.

How to Handle Set Based Consistency Validation in CQRS

This question keeps cropping up. How do you handle set based consistency validation in CQRS. In fact, one of my subscribers had this scenario:

“I have a user registration system with login/password. The login must be unique in the system. How do I implement such a requirement?”

Just in case you are not familiar with CQRS and ES, this problem arises because of something called ‘eventual consistency’.Continue reading

EventStorming – What You Need to Know

The real power of eventstorming is how it focuses on outcomes, not activities.

Why is this powerful?

It gives you options. That is according to Dan North at his recent talk at DDD eXchange in London with Skill Matter.

I know there is a lot of interest in eventstorming right now. It is of particular relevance to you if you are using DDD, CQRS and Event Sourcing. So I’ve written up my notes from Dan’s talk here. I hope you find them useful.
Continue reading

How To Validate Commands in a CQRS Application

Any of these sound familiar?

Rubbish in rubbish out.

Never trust user input.

If you’ve ever built any sort of professional application you will have had to validate user input. Whether it is to ensure a valid email address or something more complicated. There are tried and tested ‘rules’ for doing this safely while being nice the user.

1. Validate on the client side – makes for a better user experience
2. And validated on the server – never trust user input

But here’s a question..

If you issue commands rather than send in models, where should the validation occur?

The most obvious answer is in the domain model.

But this poses a problem…Continue reading

The LiveScribe 3 Smartpen [Product Review]

 

The pen is mightier than the sword. Or so they say. However, this smart LiveScribe 3 pen may just be mightier.

Picture a typical meeting…

You’ve got a whiteboard, notepad, your phone and hopefully the right people in the room. You may even have some funky planning poker cards*.

All good so far.

Now if you are into domain driven design, the chance are you’re going to want to get involved in the meeting. Listen closely to the language used and try to deepen your understanding of the domain. Or at least that’s what you’re supposed to be doing!Continue reading

Why C# Private Variables are Not as Private as you Thought

C# private fields are not accessible outside the class. It’s C# 101 right?

Which means this code should not work…

Continue reading

Is a CQRS Command = to a GoF Command?

Oh the irony.

The DDD community advocates for unambiguous language. And yet even our own terms are heavily overloaded. Whether it’s on stackoverflow like here or on the DDD/CQRS google group like here.

So, just to be clear …

… a CQRS command is not the same as the Gang Of Four Command Pattern.

But what are the differences and how best to use them? This is what I’ll cover in this post.
Continue reading

How to Send Emails the Right Way in a CQRS System

Where do you put code for sending emails? Sounds simple right? The funny thing is that if you’re adding it to a CQRS system it can be a little tricky.

Why?

It all depends on when you send them. Too early and other processes may fail and you end up sending your email half cocked. And don’t forget event replay. Could be a bit embarrassing re-sending all the emails since your app launched. I was a hairs whisker away from doing just that once!

So, in a CQRS ES system, where do you put the code to send the emails?Continue reading

How to Upgrade CQRS Events Without Busting Your Event Stream

Events are at the heart of a CQRS Event Sourced system. Which is why changing or upgrading them can be problematic. In this post I’m going to cover a few principles to bear in mind, which should help you avoid hitting the rocks. Before I dive into  ‘how to upgrade CQRS events’ I’m going to recap the role Events play in the system.Continue reading