Image may be NSFW.
Clik here to view.
Hard to believe, isn’t it?
Although both myself and Greg have been saying (quite publicly) for a long time now that we’re in agreement in about 99% of the DDD/CQRS content we talk about, it turns out the terminology we use has made it very difficult for everybody else to see that.
Anyway, on a recent call with Greg and the Microsoft Patterns & Practices team working on the CQRS guidance, I think we finally ironed out the terminological differences.
First of all, both of us clearly stated that CQRS is not meant to be the top-level architecture of a system.
The use of Bounded Contexts from Domain Driven Design is a good way to *start* handling that top-level.
The area of some contention was how big a Bounded Context should be. After going back and forth a bit, Greg brought the concept of Business Component into the conversation, and that really cleared things up all around. I was quite pleased as I’ve been going on and on about these business components for years (I think 2006 was one of my earlier posts on the topic, though the mp3 has disappeared since then).
Anyway, here’s the meat:
A given Bounded Context should be divided into Business Components, where these Business Components have full UI through DB code, and are ultimately put together in composite UI’s and other physical pipelines to fulfill the system’s functionality.
A Business Component can exist in only one Bounded Context.
CQRS, if it is to be used at all, should be used within a Business Component.
There you have it – terminological agreement in addition to the philosophical agreement that was always there.
You can find the history of my posts mentioning Business Components here.
