In your business, when was the last time you were able to reach unanimous consensus on a software solution across a diverse group of 100 people? What about with 50, 25, or even 15? The longer I have been in software development—almost 35 years as of this post—the less agreeable I find that software people are on just about any solution. Reaching broad agreement on a single definition for even one conceptual element in a business-driven software model can be impossible.
Neither of these situations is necessarily a bad thing. Everyone approaches software solutions from the position of their own world view; that is, what their experience has taught them. And whenever legacy systems are in the mix, the world view of those having worked on such a system for 5-10 years is rather locked in. Further, there may be a few or several correct definitions of any given single language term. Just look at a dictionary.
So, if you find agreement is hard among many, and that full harmony is quite unlikely among even a small fraction of many, what can we do about it? Where does disagreement leave us when trying to achieve effective software solutions?
Introducing Boundaries
I think it should lead us to boundaries. Boundaries enable autonomy. Agreement is hard. On the other hand, autonomy is not only achievable, but almost always desired when smart, experienced people are involved. If autonomy is desired, then support autonomy.
Autonomy is not only achievable, but almost always desired when smart, experienced people are involved.
Disagreement might indicate that boundaries are needed. Creating strong boundaries around every portion of your software solutions where conceptual disagreements occur can lead to overall system harmony without the need for broad consensus.
How do you create well-defined and effective software boundaries? Although other approaches may work, I suggest introducing the ideas of Subdomain and Bounded Context, which are some strategic design tools around Domain-Driven Design (DDD). My two books on this topic cover in greater—Implementing Domain-Driven Design—and lesser—Domain-Driven Design Distilled—detail these important software design tools.
Creating strong boundaries around every portion of your software solutions where conceptual disagreements occur can lead to overall system harmony without the need for broad consensus.
Consider some ways to make use of Subdomains and Bounded Contexts.
Using Strategic Design Tools
I present the use of these two tools by posing some questions about strategic design.
Q: What is a domain?
The term domain, even in DDD, is a bit overloaded in its meanings. I like to think of a “domain” as a single problem space where one or more teams are working to achieve core business initiative. So it’s neither the entire business enterprise, nor is it a single software model. It’s the number of software models needed to solve a well-defined business problem.
Q: What is the primary goal of Subdomains?
A Subdomain is simply a sub-part of a whole problem space domain; a single software model. It’s a logical area of the problem space domain that on its own delivers a portion of the overall system solution. When a system is not well designed, you will tend to see one Subdomain cut across two or more physical parts of the system, as in two or more business services, or you will see one physical business service hosting multiple Subdomains. When a system is well designed, we expect to find, for the most part, that a single Subdomain will align one-to-one with a single physical business service.
Q: Why not allow one subdomain to rule across multiple physical systems?
This is answered by the problems with agreement and the likelihood of disagreement. You can try to make this work, but you are unlikely to succeed. Across teams there will naturally be different meanings for what may appear to be shared concepts/terms. Also widespread Shared Kernel and Conformist will be hard. Since agreement is unlikely, software refactoring in one part of the system will cause unnecessary ripple in other parts that don’t really need to change.
Q: What is a Bounded Context, and why is it important?
While a Subdomain is part of a problem space, the Bounded Context is both a problem space and solution space concept. A Bounded Context is used to create a strong boundary around a single domain model. This boundary is heavily influenced by how a small set of software concepts differ in meaning in this particular domain model from those in any other Subdomains. Thus, a Bounded Context is a linguistic boundary, one where the definition of each part of the model’s language is specific and fitting in that context. Think of the best modeling situation to be one Subdomain aligning one-to-one with a single Bounded Context.
Q: How many teams work on a Bounded Context?
One. Yet, one team may own multiple Bounded Contexts. Remember, reaching modeling consensus across different teams is hard, thus we create this boundary for autonomy. It’s possible that a single team owns multiple Bounded Contexts, in which case agreement is easier because the single team has harmonized goals. In that case a team may tend to share concepts across multiple Bounded Contexts, but not necessarily.
Q: What are some examples of Subdomains and Bounded Contexts?
Although we may expect Subdomains to overlap in some ways, multiple Subdomains will often mean completely different things. For example, consider some common Subdomains in the domain of e-commerce: Orders, Invoicing, Catalog, Shipping, Inventory, Forecasting, Pricing
Among these Subdomains, would you choose to use the name “Shipping” or would you instead call it “Fulfillment”? Actually, would you split “Fulfillment” into “Fulfillment” and “Logistics”? This is a common situation, but autonomy of teams allows for disagreement with overall system harmony. Every strategic decision is far from foreordained and each company, program, project, team, etc., will have different influences, not the least of which are their own ideas of how it should work.
Q: Should DDD be used everywhere?
Ideally yes, but often it’s not possible. Although you won’t want to commit the same advanced developers to every Bounded Context, it would be best if every Subdomain were implemented inside a strong boundary—a Bounded Context. Still, you would probably be very fortunate to find many teams agreeing to use DDD across various business units. You would need to have commitment at the CIO and/or CTO level to accomplish this. Then ask, of all of Bounded Contexts in your enterprise, what is actually Core? Possibly none of the ones you might wish for or initially expect to be. Perhaps the Core Domain is all in the numbers.
The Pricing context is backed by heavy analytics, machine learning, with deep dives into current environmental conditions, significant events, and social media mining.
In the above diagram, two prominent Bounded Contexts are Matching and Bidding. In a P2P economy that’s where we make our money, right? Well, probably not. While important, these two contexts just facilitate the use of ongoing pricing victories that are won (or lost) in the Pricing context. That’s backed by heavy analytics, machine learning, with deep dives into current environmental conditions, significant events, and social media mining.
There’s Much More to Learn
This is just a glimpse at the power that DDD offers. My books and my live training workshops provide much more depth. Here are some things you will learn:
- How Bounded Contexts work with a microservices architecture
- How to integrate and collaborate among Subdomains when there are multiple Bounded Contexts
- How to implement a Core Domain using DDD tactical design
I look forward to meeting you soon!
