Why Bounded Context Really Matters

If you’ve ever heard Eric Evans speak about the big blue book that he authored, you’ll probably know that he regrets that he didn’t put part IV at the beginning. Why? well, not only are the topics covered some of the most important, he also knows that a lot of developers studied the many patterns at the beginning of the book but then stopped before reaching that critical part. If you’re one of those developers who have an interest in DDD (and really, you should) but never got far enough through to study bounded contexts, I’d encourage you to go back and give it the attention it deserves. Bounded Context is arguably the most important concept you could learn from DDD and is incredibly useful even if you’re not doing DDD.

All too often, in the software projects I’ve been lucky(?) enough to be exposed to the application is made up of one huge, inter-connected web of objects, that make it all but impossible to comprehend and even harder to safely change. We know that according to SRP objects should have one reason to change, a single responsibility. But why stop there? Why not apply this idea at the application level too? If we have an e-commerce web site, it’s raison d’etre is to take orders. That’s where it delivers value and justifies its existence so the question is, should it also be responsible for updating the inventory? Should it allow internal users to create and run reports too? And what about administration? Is that related to making a sale? Well, the answer is “it depends” of course but it’s reasonable to argue that these areas are different and might have unique needs. Each of these “contexts” likely have different forces that pull in opposing directions but if we don’t recognise them we often end up creating one of the aforementioned monolithic models that tries to be all things to all people and ends up doing none of what it was intended to do very well. It’s hard enough that the problem domain that we work in consists of what Brooks calls essential complexity but when we fail to keep our models separate we end up compounding the issue through accidental complexity.

Bounded context is a pattern that is defined as “The delimited applicability of a particular model. Bounding Contexts gives team members a clear and shared understanding of what has to be consistent and what can develop independently”. See here for more.

Finding where these contexts exist is an opportunity to produce better architected applications because you’re now building much smaller, more focused models. This has a big effect on your mental load too, not having to try and keep that huge, complicated model in your head. It’s also easier to subsequently divide work up between team members, meaning you can work on two or more distinct areas of the system without much danger of stepping on each others toes. The context considered essential to the business, known as the core domain, can be given to those developers on your team with the most experience of software development, and the most business knowledge. This is the context where you try to ensure that you really deliver the right thing and do the thing right, as the saying goes. For those contexts not considered to be core, these can be given to the more junior developers on the team, or perhaps you can buy an off the shelf product that meets the need. It doesn’t really matter, the important thing is that each context can be considered independently allowing decisions to be taken when the time is right for each one, and crucially a decision that might be considered “sub-optimal” applied in one context won’t have repercussions on the others.

Of course good things don’t come without cost, and you will need a way to communicate between boundaries whether that be through database integration (please don’t) or some sort of messaging infrastructure but it’s a small price to pay for the benefit gained from smaller, less complex models. As an aside, I really wouldn’t recommend you use database integration. If you have different bounded contexts all reaching into the same data you basically undo the good work gained from having separated them in the first place because it’s hard to tell what data belongs to which context.

For all the patterns in the book, Bounded Context is the one that has had the biggest influence on me. I could write software without ever using most of the other patterns and I wouldn’t be disadvanteged too much by their ommision but take away bounded context and I’d soon be up to my neck in it. Unfortunately, way too many projects don’t take this into consideration and are up to their neck in it. They start off small and things look like they’re going great but the complexity of that single model growing larger by the day begins to take its toll and before long the project is in trouble. The most important thing, therefore, is to realize that context is definitely king and spending some time upfront searching for those boundaries applicable to your business will pay off in a big way when the dust has settled at the end of a project.

Why Bounded Context Really Matters

Continuous Testing

One of the practices widely adopted today is automated testing of one sort or another whether it’s plain old unit testing, tdd, bdd, or whatever, chances are you’ve heard of it, and more likely you’re either doing it or you’ve at least been exposed to it. The steps involved can vary depending on how rigourous your shop is such as writing a failing test, writing the code to make the test pass, and then refactoring both the code and the test etc, but in general you always end up writing some code and then clicking the button to run your tests and then acting on the results.

While this has and continues to work well for many people there are efforts underway to help developers work more fluently still by minimising the disruption in the development workflow and thus improving productivity. This comes in the form of a number of tools that fall under the moniker of continuous testing and I’ve been evaluating one just recently called NCrunch which, as it’s in beta is currently free. NCrunch takes advantage of multicore processors in your PC to automatically detect changes to code as you type. It then attempts to build the solution in the background and if it succeeds then proceeds to run your tests giving you immediate feedback without you even having to go and click the button to run them. In fact, you don’t even need to save your file! It just happens in the background all the time. Visually, it also displays a coloured dot next to each line of code. Green indicates the line was covered by a passing test, red shows the failing lines, whilst black indicates that the line is not currently covered by a test. Left clicking on a dot pops up a window showing you the tests that cover that line, whilst right clicking gives you options like ignoring or debugging tests.

In the short period of time I’ve tried this I’ve already seen how it makes a difference to my time within the IDE and it is definitely a good experience as long as you have a capable machine. It’s not so good on my virtualised Win7 installation on my dual-core MacBook (though workable) but works great on the same environment on a quad-core iMac so it should have no problems at all on a native install. One thing I’d like to see is some kind of summary window that expresses the code coverage as a percentage to get an overall feel for the project but that’s my only wish.

*** UPDATE *** v1.39b released 16/05/2012 now has a metrics window showing code coverage as a percentage!

NCrunch isn’t the only game in town however, I know Greg Young is behind another continuous testing tool called Mighty Moose which is built on top of an open source project called AutoTest.Net but I haven’t had chance to try either of those out yet. AutoTest, I believe, doesn’t run the tests until you save or build though.

Whichever one I end up going with I think it’s definitely something that will become a permanent part of my toolbox and find its way into my everyday workflow, as the immediate feedback is such a benefit. I’d recommend you head on over to the either the NCrunch or Mighty Moose sites and check out the videos to see for yourself.

Continuous Testing