At SingleStone, our clients rely on us to help them develop technology projects from concept to completion. The goal is always for the end result to become an indispensable part of their value chain. And why wouldn’t it be? Nobody wants to pay for something that isn’t necessary, and nobody wants to build it either.
As important as value is to launching a new project, we find that it often gets lost during development. We believe that strong, cross-functional teams are the best way to prevent that from happening. Nevertheless, responsibility for projects can get chopped up in various ways—across organizations, phases, and modules—that obscure value and cause even strong teams to focus too much on technical details.
We like to use the tools of Domain Driven Design (DDD) to close the gap between business value and IT strategy. Sometimes, the projects we work on are split up in ways that make it difficult to execute cohesive vertical slices of work that provide value to a real user of the system. To put it into the language of Agile, this makes it hard to frame good epics.
So, we asked ourselves, “How might we use DDD to help frame epics in a way that both business and technical folks can understand and agree on?”
Bounded Contexts connect Priorities and Architecture
As part of our discovery process, we create a set of Bounded Contexts that describe the various parts of the business. Through Bounded Contexts, DDD creates a shared language that aligns IT architecture concepts, such as microservices, with business subdomains like “Customer” and “Distribution.” Bounded Contexts provide a framework for organizing software and prioritizing its development and are therefore very important inside the business. However, a customer who is shopping online, for example, may interact with several Bounded Contexts without realizing it. In fact, their experience should be seamless.
A word of warning for experienced DDD practitioners: I’m going to be talking about early-stage, still-speculative projects here. If you are familiar with the idea that there should be one team per Bounded Context, be aware that we are too early for that. There is only one team. I’ll also add that this approach is still experimental. If you have concerns, I’d love to hear about them!
We use Bounded Contexts in two ways
First, we test the integrity of the Bounded Contexts by mapping out message flows among them. We should be able to represent a user’s interaction with the system through a fairly straightforward set of messages passed around, as in this diagram:
In the above diagram from a medical supply business, the red numbered circles are the steps for a new customer creating an account and fulfilling their first order.
Second, we use contexts to frame the discussion about what’s a core part of the business’s unique value proposition. Does a context include something that is differentiating for the business? How easy is it for competitors to replicate?
We answer these questions by organizing our contexts on a Core Domain Chart:
For this business, the rules for collecting payments from insurers (within their Payer context) are highly differentiating and complex. This is likely an area where they would invest in custom-built solutions, as opposed to Finance or other Generic contexts where they should buy solutions in the marketplace.
The power of the diagrams is that they express both the business needs and priorities on one hand and the high-level system architecture on the other, in a way that is accessible to everyone. Moreover, because Bounded Contexts ought to be highly cohesive and loosely coupled to one another, we can make decisions about how to prioritize and implement them independently.
Using Core Domains for Roadmap Prioritization
Now imagine that this is a new business, and a small team of developers needs to decide what to build first. We have a very high-level user story: “A new customer creates an account and places their first order.” That’s pretty big! Maybe we can split it up. It turns out that steps 1–3 actually involve a physician referring a customer. That seems like its own epic. Then, steps 4–12 are the customer placing the order. That could be a second epic. Finally, steps 13–17 are where the business gets reimbursed for payments. That’s a third epic.
.png)
These are still big, but it’s a good start. Which of the three should they do first? Well, they want to focus on their core value proposition. Steps 1–3 involve the Marketing, Sales, and Customer Bounded Contexts. Those seem kind of important, and in our Strategic Classification, the Customer in particular is highly differentiating. But it’s not very complex, so it doesn’t quite make it into the core.
What about placing the order (steps 4–12)? Step 7 touches the Payer Bounded Context. According to our classification, Payer is most squarely in the core. This epic also involves Customer and Order, which are on the periphery of the core. It looks like a great opportunity to focus the most valuable development resources on something that is both highly differentiating and highly complex. Nothing in steps 13–17 is fully in the core, so now our team knows where to start!
What’s more, the team can point to these diagrams and say, “We’re going to start by building the parts of the system where the Customer submits an Order and it is verified using the Payer rules, because that is what captures the most business value and is most in need of de-risking.” Everyone knows what they’re doing and why, and the engineering team can begin breaking that down into smaller stories and working out the implementation details. At the same time they know what subsystems they are dealing with and have a good idea of the responsibilities of each.
As this business grows, it may have multiple development teams, each one working on one or a few of the Bounded Contexts independently. But because it is currently small and there is only one team, the choice of where to start can be overwhelming. By using these two diagrams, we can bring all the stakeholders into this discussion and move forward with everyone in agreement about what matters most for getting a new project off on the right foot.
Using DDD for strategic framing in Agile
We’re strong believers in using both DDD and Agile to zero in on the right problem so that we can solve it quickly with minimal risk. Yet, as powerful as these tools are, they naturally lend themselves to different phases of the project: DDD for design and Agile for execution. We wanted to stop information from getting lost between phases by making the strategic framing afforded by DDD an explicit part of our Agile process. This approach gives us a natural way to create strong epics and keep them grounded in our discovery work.
I encourage others to embrace the synergy between DDD and Agile to elevate project outcomes and deliver meaningful solutions. Happy to discuss this further, reach out with any follow up comments or questions!
