Eventual Consistency and Business Alignment

mapI recently discovered through eventual consistency that my bounded contexts were not properly aligned with the business.   I won’t lie, it took me quite a while to make this realization.

This was most likely the case in many situations I’ve had in the past.  Because of this realization, I wanted to let out some of my thoughts about eventual consistency and business alignment.

Dependent Bounded Context

I’ve often encounter situations where a bounded context requires information that another bounded context is responsible for.  I’d like to use a simple example I’ve heard from Udi Dahan.  In the context of an Ecommerce site.

  • A customer can be a defined as a “preferred” customer.
  • Preferred customers receive a 10% discount on all orders.

Based on the above, the “preferred” flag and any business rules associated to it, most likely exists in some sort of the CRM bounded context.  However, this detail is required in the Sales bounded context in order to apply a discount if eligible.

As you can see, there is information that needs to be shared between bounded contexts.

Publish / Subscribe Domain Events

One approach for decoupling your bounded context is to publish domain events from your domain model.  This allows other bounded contexts to subscribe to those events and handle them accordingly.

Let’s use our example above to see how this would be implemented.  In our CRM bounded context, when a customer is defined as preferred in our domain model, we would publish a CustomerIsPreferred event.

class CustomerIsPreferred
	public Guid CustomerId { get; private set; }
	public DateTime Date { get; private set; }
	public CustomerIsPreferred(Guid customerId, DateTime date)
		CustomerId = customerId;
		Date = date;

In our Sales bounded context, we would subscribe to this event and update our customer model with a preferred flag. This piece of information is used as a local cache in our Sales bounded context.

During our checkout process in Sales, we would then use the preferred flag on the concept of a customer in Sales to determine if they should receive a 10% discount.

However, remember that this preferred flag is not owned by Sales.

Because of the publish / subscribe model (assuming asynchronicity), at any given time, our preferred flag in Sales could be out of sync with current state in our CRM bounded context. Eventually consistency doesn’t mean our data is wrong, it just means it is stale.

Business Alignment

There are many situations where data being eventually consistent is totally acceptable.  I’ve found in the real world we often make decisions with stale data all the time.

However, there are times where full consistency is required.  When describing the example above to the business, does the eventual consistency of the preferred flag have true business impact?  If it truly does matter and the data must be fully consistent, then you may have bad business alignment with your bounded contexts.

Re-evaluate your bounded context and the boundaries as you may have an wrong interpretation of responsibilities.

I’ve found that drawing a context map and the events which are published and subscribed with a domain expert should flush out any of these incorrect interpretations and help you re-align boundaries and responsibilities.

My F# Journey – F# Learning Resources

F# CloudThinking about learning functional programming with F#?  Here is a list of F# learning resources that will help you on your own F# journey.

Robert C. Martin – Functional Programming: What? Why? When?

Why is functional programming becoming such a hot topic? Just what is functional programming anyway? And when am I going to have to know about it? In this talk Uncle Bob will walk you through the rationale that is driving the current push towards functional programming. He’ll also introduce you to the basics by walking through some simple Clojure code.

F# Software Foundation


A wealth of information.  There are some very useful walkthrus on how to use F# on various platforms (Windows, Linux, Mac).  As well, there are many guides on how to use F# for Web Programming, Mobile, Cloud, Financial, etc.

Try F#


There is an interactive window that allows you to write and execute F# directly in your browser.  This is nice if you want to experiement with F# without having installing F# or an IDE.

F# for fun and profit


I found this site very approachable coming from an enterprise and line of business development background.  I found it to be an easier read than most.

Domain Driven Design, Event Sourcing and CQRS with F#

Ever since I discovered the “blue book” by Eric Evans, I’ve been immersed in Domain Driven Design, Event Sourcing, CQRS, and Messaging.  If you are familiar with these concepts than this talk by Lev Gorodinski is worth a watch.




When you are ready to jump into some real code take a look at the Todo MVC app written in F#.


If you have any suggestions, please comment and let me know which sites/resources you have found helpful.

My F# Journey – What I’ve learned so far

fsharpThis is a first blog post in a series to document my experiences while learning functional programming. This is my F# Journey.

During my 15 year career that started in the late 90’s, I have not made very many conscious decisions about learning a specific language or technology.  The path I’ve taken and the experience I’ve gained seems like it just happened naturally.

As someone always wanting to learn, I usually find some interesting topics and start going down the rabbit hole (Domain Driven Design, CQRS, Event Sourcing… thanks Greg Young), however I never usually set out on a “I’m going to learn X” journey.

That’s about to change.

As with anyone that keeps up with the latest trends, functional programming is all the rage.  And I do believe for good reason (more on that later),  which is why I’ve decided to take on the journey of learning with F#.   I’ve chosen F# because of my .NET/C# background and feel it can help my career to keep it in the .NET ecosystem.

What I’ve learned so far…

Stop comparing it to C#


It’s natural when looking at another imperative language that you are unfamiliar with, to compare it to the language you know best.   The concepts are all transferable.  How do I perform a loop?  How do I define a variable?  How do I assign a variable?

With a quick search and reading a few examples,  you are off to the races writing some basic code in a new imperative language.  Stop trying to compare concepts.

Let it go!

Open up your mind to new ideas and try and forget everything you know.

Think like a beginner.

Just because you can, doesn’t mean you should

Because F# is a hybrid language and supports some of the concepts of an imperative language, doesn’t mean you should use them.  In pure functional languages, there are no loops or objects.

Let it go!

Just because you can use F# in a non-functional way, doesn’t mean you should (especially while learning).

When reading intro articles, you will see the following statements over and over again: “start thinking functionally” or “start thinking differently”.  It’s hard at first to really grasp what this really means.  Once you finally let go of the imperative way of thinking, you will get an “AH HA!” moment.

Read & Play

Anytime I’ve ever learned a new language it has always been through practical use in a small app.  However, I do find that learning the basics of F#, understanding F# types, and thinking like a beginner before jumping into real code has been helpful.  I’m using Visual Studio and writing code, but more as a playground than attempting actually write an app.  Once I feel comfortable enough and actually feel like I fully “get it”, I’m going to start writing a simple app.