Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Start Your Architecture Modernization with Domain-Driven Discovery

Start Your Architecture Modernization with Domain-Driven Discovery

Key Takeaways

  • Architecture modernization projects are complex, expensive, and full of risks. Starting with a Domain-Driven Discovery (DDD) focuses your team and improves your chances of success.
  • Start with problem framing to clarify the outcomes, then use event storming and the C4 Model to illuminate the current state before diving into solutions.
  • Analyze the current state to identify your bounded contexts, then create a birds-eye view with message flows while strategically classifying your contexts with Core Domain charts.
  • Align your systems, data stores and cloud environments to your bounded contexts to increase transparency and reduce complexity, building a common language as you go.
  • Create a flexible roadmap and evolve your architecture to the desired future state over time to avoid risky rewrites.

Successful projects start with robust discovery. For teams building new digital products and services this often includes conducting user research, gathering requirements, and creating a backlog before you write a single line of code. But what if your project is modernizing your tangled old legacy system or migrating all your workloads to the cloud? How can you start the projects with the confidence you have when launching a new product?

This article presents a guided approach to starting your next architecture modernization project with a Domain-Driven Discovery (DDD). To illustrate, we will use one of my customers, a medical supply company that is migrating all their core systems to the cloud and needs to create a future state architecture and a plan for getting there.

We break down the key steps and common visuals to give your team the confidence it needs to create your future state architecture using Domain-Driven Design. You’ll be able to use this article as a reference to modernize the architecture of a single system or a portfolio of systems.

Start with Discovery

There was a time when we started new Agile projects with a two-week Sprint 0 then launched right into coding the solution. Unfortunately, teams often found out later they wasted time and money on "building the wrong thing righter." The influences of Design Thinking and Dual-Track Agile and frameworks like Mobius have opened our collective eyes to the importance of a brief discovery for product work.

But for the last five years, I have applied Domain-Driven Design to architecture modernization projects with customers of all sizes, from start-ups to Fortune 100. This experience, combined with investments in team training, has helped us learn how to run time-boxed DDD projects that increase our chances of success for architecture modernization projects.

This article provides your teams with a blueprint for architecture modernization projects in four integrated steps:

  1. Frame the problem – Clarify the problem you’re solving, the people impacted, desired outcomes and solution constraints.
  2. Analyze the current state – Explore the existing business processes and systems architecture to establish a baseline for improvement.
  3. Explore the future state – Design a modernized architecture based on bounded contexts, set strategic priorities, evaluate options and create solution designs for the future state.
  4. Create a roadmap – Create a plan to modernize the architecture over time that’s aligned to the desired workstreams or outcomes.

[Click on the image to view full-size]

Figure 1 - Domain Driven Discovery overview

Step 0: Strategic or Tactical DDD

Before beginning, identify the level you’ll be working at:

  • Strategic DDD – Example: using DDD to modernize a portfolio of systems. Migrating applications to the cloud and creating a modern architecture for complex legacy systems.
  • Tactical DDD – Example: using DDD to modernize a single system, such as re-architecting a web application or building a new product.

In our experience, a small team can complete a Tactical DDD discovery in 4-6 weeks. A Strategic DDD discovery typically takes the same team 8-12 weeks to complete.

Discovery Team

Role Skills Allocation
Technical lead Architecture Full time
Analyst Process Full time
Domain experts Current state knowledge Part time
Technical experts Architecture Part time
Delivery lead Project management Part time

Discovery Schedule

Steps Tactical DDD Strategic DDD
1: Frame the problem 1 day 1 day
2: Analyze the current state 2-3 weeks 3-4 weeks
3: Explore the future state 1 ½  - 2 weeks 3-5 weeks
4: Create a roadmap ½ - 1 week 2-3 weeks
Total: 4-6 weeks 8-12 weeks

We have found that time-boxing discoveries creates a focused sense of urgency, helping teams avoid analysis paralysis. Because it uses two-week increments, DDD fits nicely into existing Agile team schedules. Before you begin, assemble the right team, create a schedule, and get started!

Step 1: Frame the problem

Within architecture modernization projects, there is often a lot of lip service given to using modern technologies like micro services, serverless, Kubernetes or service meshes, etc. What people tend to gloss over is the problems they are trying to solve and the outcomes they hope to achieve. But that’s where you should start.

Begin with a two or three-hour workshop organized around a shared Miro board and a set of exercises, asking the team to work as a group to clarify:

  • Problem - What problem(s) are we solving?
  • People - Who are the people impacted?
  • Outcomes - What does success look like?
  • Constraints - What are the constraints that we need to consider?

It’s important to align on the answers to these questions. 

For our medical supply customer, problem-framing was especially helpful for defining successful outcomes of improving resiliency and maintainability of their core systems. Simply migrating to the cloud and running in multiple regions would address resiliency. But during this step the team came to understand that they also needed to improve maintainability in the long-term because their complex architecture had grown organically over 15 years.

[Click on the image to view full-size]

Figure 2 - Problem statement, stakeholders, outcomes and constraints

Framing your architecture modernization with outcomes clarifies the "why" behind the project for everyone involved. It also establishes baselines for improvement and encourages setting targets so you can measure progress over time.

Step 2: Analyze the current state

With the problem framed, you’re ready to dive into Step 2. During this step, you’ll focus on two things in parallel: business processes and systems architecture.

We suggest using event storming workshops to clarify the business processes related to the in-scope systems. Start by choosing a primary process or experience to focus on, such as a new customer registration. Next, collaboratively identify every event in this end-to-end process. It’s important to focus on how it works today, not how it should work in the future. Then identify a subset of the events that are essential to the process and labels these Pivotal Events. As a rule of thumb, you should be able to describe the end-to-end process to a lay person using just the Pivotal Events.

For a Tactical DDD project, a single workshop with some follow-up discussions is typically enough. For a Strategic DDD project, you might need to host multiple workshops focused on different users and processes. I recommend starting with one workshop during the first week, then scheduling additional workshops as needed. For Strategic DDD, you don’t need an exhaustive list of every event in the entire organization, just enough that you can confidently demarcate your bounded contexts related to the portfolio of in-scope systems.

During these workshops, a common language emerges that you should pair, with the visuals, to orient everyone to a common view of how things work today.  

For example, here is the event storm for our medical supply customer. Figure 3 shows the events around initial customer registration.

[Click on the image to view full-size]

Figure 3 - Details of initial customer enrollment

Figure 4 zooms out to reveal the entire new customer journey, with some of the details obscured.

[Click on the image to view full-size]

Figure 4 - Event storm of new customer journey

In parallel, you should dive into the current state architecture. We like C4 models for their simplicity and suggest starting with a Context (C1) diagram that puts the in-scope systems in the middle so you can see the entire ecosystem, including integrations.

[Click on the image to view full-size]

Figure 5 - Current state context diagram (C1)

Next, you’ll drill down to create the Container (C2) diagram that illuminates the different components such as web applications, backend services, databases, and messaging. Like event storming, this is often done in a workshop during the first two weeks with follow-ups as needed. It is critical to get this as accurate as possible so that future state recommendations are grounded in reality. 

For our medical supply customer, the C2 diagram illustrated the complexity of their core systems, which we had to factor into their migration plan and longer-term architecture modernization. Figure 6 shows how different personas interact with the portals that are connected to their order management system.

[Click on the image to view full-size]

Figure 6 - Customer interactions with portals connected to the orders system

Figure 7 zooms out to reveal all the components in their ecosystem and how they are connected.

[Click on the image to view full-size]

Figure 7 - Current state container diagram (C2) shows complexity of current systems

At a minimum, we create event storms, context diagrams (C1) and container diagrams (C2) for every project. Depending on the type of project, we might complement these with additional visuals. 

Step 3: Explore the future state

Now that you have a solid understanding of the current state, you can move on to Step 3, creating a future state based on bounded contexts aligned to the business model. These bounded contexts will guide the team on their architecture modernization journey and ensure the technical architecture is grounded in how the business works. When exploring bounded contexts, look for areas of high cohesion and low coupling within the in-scope business processes and systems. 

We do this by cloning our event storm then using a red marker to identify potential bounded contexts. Figure 8 shows this for the medical supply company.

[Click on the image to view full-size]

Figure 8 - Event storm with draft contexts

When deciding where to draw the boundaries, Pivotal Events often provide clues but this is no standard formula. When in doubt, start with fewer contexts and then adjust based on feedback. In Tactical DDD projects we typically uncover 10 or fewer business-oriented contexts. For Strategic DDD projects, we may identify double or triple that number. Remember to name the business-oriented contexts using terms your domain experts agree on and add supporting technical contexts such as shared services and analytics.

Refine bounded contexts with message flows

Next, you’ll create a diagram of Bounded Contexts with Message Flows that clarifies how messages are sent between contexts. Figure 9 shows a detail view of the customer and order contexts:

[Click on the image to view full-size]

Figure 9 - Details of customer and order contexts

Figure 10 zooms out revealing a bird’s-eye view of all the contexts in the organization with numbered messages to illustrate the steps of a new customer journey. 

[Click on the image to view full-size]

Figure 10 - Bounded contexts with message flows diagram

The centerpiece of a DDD is a one-day workshop that validates the outcomes of steps 2 and 3. Schedule this workshop for about midway through the project and be sure to invite domain experts, tech experts, and key stakeholders to participate. 

During this workshop, the discovery team walks participants through the bounded contexts and message flows, working one step at a time, clarifying terminology in real time with the domain experts. The team will add some arrows and remove others. You should expect spirited debates about naming and how things really work. While the domain experts work toward alignment, the technologists should connect the dots, confirming how the entire system fits together.

During this workshop with our medical supply customer, their domain experts recommend splitting out Revenue Cycle Management into its own context, rather than lumping it in with Payer. The discussion that followed helped everyone understand the differences between the two contexts. We re-aligned the messages in real-time and most importantly, the whole team aligned on a shared language and understanding of how messages flow between contexts.

Explore options before solutions

Architecture modernization projects often start with a general idea of where they are headed based on an enterprise vision or strategy, but there’s more than one way to get from A to B, so there are plenty of options to explore. Before jumping to solutions, spend some time exploring your options. The breadth of options you review and the depth of analysis will depend on the type and scope of the project as well as client culture, but you should timebox this effort. 

You might, for instance, evaluate whether Amazon Web Services (AWS) or Microsoft Azure is a better fit, or whether using a cloud-managed database offers advantages over running a database on a virtual server. You might also consider multiple ways to re-architect the current system and databases to better align them to future state bounded contexts.

I always insist on options before solutions because it forces the team to think through multiple ways to solve problems. The result is often some combination of the best aspects of each approach, which typically produces better outcomes.

Strategically classify your bounded contexts

In DDD we like to use Core Domain Charts to clearly determine which contexts are the most important strategic differentiators, enabling us to align investments accordingly. We often engage executive leaders in this process to reveal strategic insights, such as:

  • When should we build custom software versus buying from market vendors?
  • Where should we increase or reduce investments in the future?
  • Based on our business strategy, how will our contexts evolve over time?
  • Do we expect new contexts to emerge based on our business model or strategy?
  • How do our current investments in people and systems align to our bounded contexts?

[Click on the image to view full-size]

Figure 11 - Strategic classification of contexts

To begin answering these questions, establish today's baseline using the scales of model complexity and business differentiation. During the workshop, take your new bounded contexts and pull them into the chart one-at-a-time, adjusting their relative positions on the x and y axis as you go. Start by asking the leaders, "What contexts do you consider to be your competitive differentiators?" and pull these contexts into the Core part of the chart. Next, ask, "What contexts are not unique to us?" and pull these into the Generic part of the chart. The remaining contexts belong in the Supporting part of the chart. They are business necessities but offer limited return on investment (ROI). Continue to adjust the diagram as you add new contexts. Lastly, introduce Experimental as a place for big bets that could disrupt the company’s business model or their industry.

As Figure 11 shows, our customer’s Payer context was their "secret sauce" and the biggest market differentiator, followed by their Customer context. On the other hand, Revenue Cycle Management was complex but not unique to them. This insight revealed an opportunity to replace their custom-built solution with a vendor’s solution to improve maintainability of their core systems.

This workshop should be a democratic process with lots of back-and-forth about where each context belongs on this chart. When you’re done, you have a unique visual that strategically classifies the building blocks of your architecture: your bounded contexts. In my experience, this is often when executives "get it" and begin to appreciate the clarity that DDD brings. Teams benefit, too, because they understand where building custom solutions make sense (Core domains) versus where commercial off-the-shelf (COTS) solutions will do (Supporting and Generic domains). This workshop helps you avoid building the wrong thing righter!

Align future state architecture towards bounded contexts

With your contexts identified and strategically classified, you have the building blocks for a future state architecture aligned to your business model. From here you can start turning options into a solution design.

The design topics covered at this point during discovery are highly dependent on the type of modernization project you’re tackling. For Strategic DDD projects like cloud migrations, you’ll focus on cloud foundation capabilities, network and security boundaries and workload deployments. For Tactical DDD projects like a new web application, you’ll focus on micro services, API’s and the data model. 

For our medical supply customer, design focused on 1) migrating applications to the cloud and 2) re-architecting their applications into micro-services aligned to contexts including databases, event messaging, API gateways and deployable components. We used the container (C2) diagram to visualize what a future state could look like and how it differs from the current state. Figure 12 highlights the components of the customer and order contexts.

[Click on the image to view full-size]

Figure 12 - Components of customer and order contexts

Figure 13 zooms out to see all the components of the future state architecture aligned to bounded contexts, with shared components like a federated API gateway, message bus and data warehouse spanning multiple contexts.

[Click on the image to view full-size]

Figure 13 - Future state architecture container diagram (C2)

There is no workshop per se for creating and refining these designs. We often work on them during multiple small group sessions. Technical leads usually create these diagrams by working closely with customers and experts who provide input and feedback along the way. We suggest keeping all your diagrams on a single virtual board so everyone can review them asynchronously and comment on the design as it evolves. Your team should also research the capabilities and limits of the technologies being considered for the future design. 

Until this point, we’ve focused on bounded contexts that support the business domain. But what about technology services that support the basic operations of any organization? How are they modeled as bounded contexts? Over time, we have identified several that should be added to support the business-oriented contexts:

  • Shared services context - Common DevOps tools, networking, logging, messaging, monitoring, and other services used by business-oriented contexts.
  • Security services context - Identity, authentication and other security tools.
  • Analytics context - Data warehouses, analytics, data transformations, machine learning, reporting and other data tools
  • Audit context - Audit logging and compliance tools

Sometimes it makes sense to break out networking into a separate context and other times you can simply include it in Shared Services, it just depends on your infrastructure architecture.

Design activities can easily expand to the amount of time you give them, so limit this step to a few weeks. This is enough time to create a future state reference architecture that can serve as a starting point. You can tackle the remaining design decisions during implementation. The goal is to get to a "good enough" spot and then proceed to creating a roadmap. 

Step 4: Create a roadmap

The last step before implementation helps you define the work, sequence and schedule necessary to create the future state architecture. We suggest using a simple table of columns representing flexible time horizons (Now, Next, and Later) and rows of workstreams or outcomes to represent ways to group the work, as seen in Figure 14.

[Click on the image to view full-size]

Figure 14 – Future state roadmap with recommendations

For our medical supply customer, we started by identifying an important milestone that needed to be completed by the end of the Now phase: all their applications needed to be "ready to migrate" and their cloud foundation had to be ready to securely host workloads. The team aligned on what this meant, and quickly created the first draft of the roadmap. Anchoring to this milestone helped them define what had to be done in the Now phases versus what could wait until Next and Later. Figure 15 shows some of the initial items on their roadmap.

[Click on the image to view full-size]

Figure 15 - Details of roadmap's Now phase

Once you have a draft roadmap, socialize it to get feedback from the stakeholders during review meetings and workings sessions. We typically start the roadmap two to three weeks before the end of the discovery phase, giving us time to collect and iterate on feedback with the working team before presenting the roadmap to executive stakeholders.

Clarify your architecture evolution steps

The final phase of DDD is creating a clear view of the architecture evolutions from current to future states. You should do this work in parallel with the roadmap development since the technical lead will create the visuals that represent the interim states of the architecture at the Now and Next milestones. The team should discuss each visual to clarify the changes necessary at each evolutionary step, revising the roadmap as they work.

We often see the anti-corruption pattern as people transition to Domain Driven Design. This is a layer of software that isolates the newer bounded context-based architecture from your existing architecture that serves as a helpful bridge as you evolve to a future state. While this software has a temporary lifetime, it can live as long as it takes you to complete your transition. Additional work to design, code, test and deploy this software affords you time to transition from current to future states and reduce the risks associated with re-writing all your systems at once.

From discovery to delivery

In a brief amount of time your team can use DDD to:

  • Clarify the problem you need to solve, people impacted, desired outcomes and solution constraints.
  • Analyze your current business processes and systems architecture.
  • Identify your bounded contexts and message flows.
  • Strategically classify your contexts to align investment and decisions.
  • Design a new future state architecture aligned to your bounded contexts.
  • Create a roadmap for getting from current to future states aligned to business value.
  • Visualize the evolutionary steps for your architecture.

Post-discovery, you should distill the results into an actionable plan that includes (but is not limited to): 

  • Building a product backlog of epics based on the roadmap.
  • Creating a release plan for the Now phase.
  • Setting up development environments with access.
  • Aligning on team norms and meeting cadences.
  • Additional research and design work to refine the architecture.

Using a shared digital whiteboard to do this work provides clarity and transparency as well as simpler onboarding for anyone who joins the project later. I am currently working on a Miro template for all the steps in DDD and will update this article with the link once published.

Get started with DDD

Successful projects start with robust discoveries. Before you begin another architecture modernization project, consider using our four-step DDD. This collaborative approach, designed for cross-functional teams, aligns strategy with architecture in a transparent way while building a shared language for leaders and technologists. In a brief amount of time, you’ll get clear insights to guide your project, which will help you save time, effort and money. 

A special thanks to Abby Franks, Ben Linders and Kate Neale Cooper for their help with this article.

About the Author

Rate this Article