CEO Guide to Domain Driven Design

This is the 3rd article in a series of Monoliths, Microservices, and how move from Monoliths to Microservices. 

One of the most challenging transformations for a digital company is splitting or merging a monolith. 

Our prior blog post CEO Guide to Breaking Up the Monolith describes a current state. Some highlights:

  • Description of a monolith - typically a single codebase and database that delivers a digital service
  • When a monolith is good or bad - good for early stage, may not be good for later stage
  • Leading indicators to know when it is time to split the monolith - e.g., feature delivery isn't fast enough and availability isn't high enough

Our follow-on blog post CEO Guide to Microservices describes a desired future state. Some highlights:

  • Description of microservices - the desired size of any service for optimal team size, time to market, and availability
  • When microservices are good or bad 
  • Decision tree when a codebase and database should be split into smaller services

This article describes a critical skill needed to split monolith into smaller services. This skill is Domain Driven Design (DDD). It is the best technique that we have found to safely move from Monoliths to Microservices.

What are Domains?

Eric Evans describes a domain as 'A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.'  

The 1st article mentioned above (CEO Guide to Breaking Up the Monolith) uses an eCommerce example. The domains in that article were: 

  • Customer Accounts
  • Inventory
  • Shipping


These domains look like organizational boundaries. That is, the sales team owns the creation of customer accounts. The customer account information is stored in the customer table in the monolith. This monolith could be an ERP, eCommerce engine, or an internally built solution that has elements of both ERP and eCommerce.

However, real world domains are seldom this well organized. In the example of Customer Accounts, this data and information changes throughout the customer journey. Before a customer is a 'customer', they are a 'lead' or 'opportunity'. This information is owned by Marketing and Sales. This information is often in 1 or more systems.

After the customer is onboarded, customer information is often stored in an eCommerce platform. It may also be copied to a Customer Support Solution. After years of company growth, the domain 'Customer Account' spans many systems and teams.

To understand how data and information should flow through the organization:

  • Domain boundaries may need to reestablished - after each stage of growth or an acquisition
  • Architectures may need to be changed - to move data to the right processes
  • Teams may need to be reorganized - to properly support the architecture and processes

Why are Domain Boundaries Important?

Without clear domain boundaries:

  • people (business employees and customers),
  • processes (how employees interact with customers),
  • and technology (architecture and engineers supporting the processes)

change at different rates. This can lead to inefficiencies. Inefficiencies lead to friction and waste. Friction and waste lead to emotional frustration. Emotional frustration leads to political turf wars. 

Domain boundaries make it easy to keep people, processes, and technology in sync. This in turn reduces friction and politics.

What is Event Storming?

Event Storming is an exercise to identify Domain Boundaries - from the customer and market perspective.  It is called 'Event Storming' to identify business 'events'.  Events are 'something happened'.  For example, 'Customer order submitted'.  These events capture the logical order and dependencies of business activities so that software can be properly modeled.  The logical order makes it easier to collectively identify Domain Boundaries.  The word 'Storming' is used in order to get a holistic view from the business vs technical view and from the internal vs external view.   

Event Storming occurs in a large physical or virtual room. Sticky notes capture key information for business and engineers to understand how one or more systems work today. The language on sticky notes is clear and concise. A handful of colors represent different attributes. The colors represent a common language. Participants understand the language in the first 1-2 hours. 

Pre-COVID, attendees all gathered in large conference rooms. Post-COVID, attendees have transitioned to white board platforms such as Lucid and Miro.
Event Storms are 3 to 6 hours long. This is an optimal duration to capture the right amount of information while not exhausting attendees.

Experienced practitioners lead event storms. A mix of long tenured employees and a handful of new hires as participants provide the best results. A few simple rules of engagement and a strong facilitator keep the Event Storm on track and on time.

The output of an Event Storm is:

  • A shared understanding of how customers interact with the current platform(s)
  • Pain points for customers and/or engineers
  • Opportunities to resolve quick issues and size large efforts
  • Clear boundaries of business domain boundaries
  • Clear boundaries who owns data at each stage of a customer journey or business process

The output of an Event Storm is NOT:

  • Ready for consumption by non-participants
  • A firm long term roadmap

Key Points for CEOs and Board Members

  1. Engineering cannot lead or define domain boundaries without Product and other business stakeholders. If a CTO or Engineering leader has held an Event Storm or Domain Driven Design exercise, ask for key participants. Ask at least one participant from the business and one from the technology team about the Event Storm. 
  2. Event Storming is the best technique we have found to identify where to split the digital architecture. Other exercises are valuable, but they do not bring business and engineers together as well as Event Storming. Event Storming looks like Journey Mapping and Process Mapping. Those techniques are a good foundation to eventually become an Event Storm leader. 
  3. An experienced person should lead the first 1-3 Event Storms. This person may not exist in your organization. These experienced practitioners are still small in numbers. These experts have 10 or more years building new solutions in several markets.

Common CEO Questions about DDD and Event Storming?

When do I need to run an Event Storm and Domain Driven Design? 

Due to the number of stakeholders, only suggest an Event Storm and DDD when you need to split a monolith or large service. See our 'When to Split a Service' in this article.

Who should organize an Event Storm? 

A leader in Product or Engineering should organize it.

Who should attend an Event Storm? 

Multiple departments should be involved.  At a minimum, Product and Engineering must be in attendance. Ideally, Sales, Marketing, Operations, and Customer Support are also represented.

Will Event Storming and Domain Driven Design solve all of my product and engineering problems? 

No. It will identify where and how to solve many difficult customer impacting problems and opportunities. Implementing DDD is a transformation. See our article on How to Lead Transformations. 

Can my team read a book and do this themselves? 

Unlikely, but a handful of your team should read the books listed below. The books are very helpful for Engineering and Product stakeholders. But, Event Storming is best learned from experienced practitioners. These books will speed up the learning for the team:

What similar work has my team done to help with DDD and Event Storming? 

Our article Big Picture Artifacts to Connect Strategy to Architecture identifies several artifacts that connect the market, your capabilities, and your architecture. Some of these artifacts are:

  • Journey Maps
  • Process Maps
  • Feature Matrix
  • Architecture Diagrams (Business Friendly)

Where can I get help?

AKF Partners specializes in transformations for digital companies. Our team has the business and engineering expertise to lead engineers, product managers, and executives through a transformational change. Most of our team has both engineering degrees and MBAs. Most of our team has over 20 years of experience solving these types of problems. Contact us to see how we can help.