Bounded Context and Subdomains

CarpetIn a previous blog, I discussed how I recently discovered through eventual consistency that I had poor business alignment.  With more thoughts and insights, I wanted to extend that post by discussion bounded contexts and how they fit within subdomains.

1 to 1?

I’ve often thought of a bounded context as being a one-to-one relationship with a subdomain.   To take that further, you may get the impression that they are indeed the same thing.  When I was first introduced to the concept many years ago, I was under the impression that they mapped directly one to one.

I’m not entirely sure why I had this perception early on.  It may be due examples or just the assumption I made.  I do not remember actually ever reading how a subdomain and a bounded context don’t map directly one to one.

Over the years I’ve realized this not to be the case, but always had a tough time giving an explanation that others could visualize.

I heard Eric Evans gave a great example that I will paraphrase, which should help you visualize the difference.

Living Room Floor

Imagine a room in your house.  It may have a closet or some different length walls which makes it not totally uniform.  Imagine there is carpet in this room.  The carpet covers every inch of the floor.  Wall to wall carpet.

This carpet represents your bounded context.

Underneath the carpet, say the cement, is your subdomain.

By Design

It just so happens that your bounded context is mapped to your subdomain exactly.  However, that is just because the bounded context (carpet) was designed that way.

A bounded context doesn’t necessarily need to cover the entire subdomain.  It only needs to cover the aspects of the subdomain which help solve the problem space.

To use the carpet analogy again, I mentioned that the room wasn’t completely uniform as maybe it had a closet in it.  The carpet doesn’t need to cover the entire floor beneath it.  There may be bare floor exposed in the closet because that portion of the subdomain doesn’t require to be modeled as it isn’t needed for problem you are trying to solve.

More Than One?

I’m still trying to determine if a subdomain can have more than one bounded context.  I do think it may be possible if you are implementing something technical apart of that subdomain.  I would love to hear others thoughts on this.

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

http://fsharp.org/

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#

http://www.tryfsharp.org/

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

http://fsharpforfunandprofit.com/

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.

 

ToDo-Backend

https://github.com/panesofglass/TodoBackendFSharp

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

More…

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