Domain-Driven Discovery

Overview

Domain-Driven Discovery

Blueprint 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.

before you begin

Strategic or Tactical DDD

Before beginning, identify the level you’ll be working at. 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.
‍
Strategic DDD: Using DDD to modernize a portfolio of systems. Migrating applications to the cloud and creating a modern architecture for complex legacy systems.

Tactical DDD: Using DDD to modernize a single system, such as re-architecting a web application or building a new product.

Step one

Frame the Problem

Where to begin?

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.

Step two

Analyze the Current State

Clarify the business domains

To illustrate these steps, we will reference a medical supply client of ours that migrated all their core systems to the cloud. We suggest an activity known as "Event Storming" to clarify the business processes related to the in-scope systems. Above is an output of an event storming workshop for said client, with a focus on the initial customer enrollment process.

Clarify the systems domains - Context View

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.

Clarify the systems domains - Container View

Create container (C2) diagram

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. The visual above shows our client's customer interactions with portals connected to the orders system.

Current state container diagram (C2)

The C2 diagram totally zooms out to reveal all the components in their ecosystem and how they are connected. 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.

Step three

Explore the Future State

Refine bounded contexts with message flows

Create draft bounded 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.

Bounded contexts with message flows diagram

The graphic above zooms out to reveal a bird’s-eye view of all the contexts in the organization with numbered messages to illustrate the steps of a new customer journey.

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 around the trajectory of the business.

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 figure above highlights the components of the customer and order contexts.

Create Future State architecture - Container View

This figure 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.

Step four

Create a Roadmap

Future State Roadmap with recommendations

he 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

Focus on the 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.

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

Get connected with an expert