Domain-Driven Business Analysis
Dividing and Conquering Business Complexity
At the turn of the millennium, organizations automated business processes to gain a competitive edge, providing clients with valuable information and online experiences. Business processes grew more sophisticated as customer demands accelerated. A need arose to manage this booming complexity.
Domain-driven design deals with complexity by organizing software development around business contexts known as domains. Each domain has specific concepts and domain experts.
For example, Salesforce offers solutions in three domains.
| Domain | Salesforce Solution |
|---|---|
| Marketing | Marketing Cloud |
| Sales | Sales Cloud |
| Customer Service | Service Cloud |
Domains like these carry a lot of complexity. Breaking them down into subdomains reduces them to manageable challenges. For example, the marketing domain could have subdomains for advertising, email, and social media marketing.
Guiding Business Analysis with Domain Types
Domains and subdomains have three types:
A Core Domain contains strategic solutions that differentiate the organization from its competitors.
A Supporting Subdomain contains common solutions required by a core domain.
A Generic Subdomain contains standard solutions for other subdomains, like identity services or reporting.
Business analysts pay the most attention to determining requirements in the core domain - those that bring the highest value to the organization. Solutions in the core domain give the organization a competitive advantage.
Business analysts ensure that supporting subdomains meet core domain requirements. A supporting subdomain could contain an existing solution like Salesforce, customized to meet core domain requirements.
Generic subdomains usually contain off-the-shelf software to complete the overall solution.
A Domain-Driven Retailer
Let’s say a new retailer wants to offer customers convenient access to their products and services through social media, their website, and text promotions. This customer journey intends to give the retailer an advantage over their legacy competitors, delivering more value to their customers. The custom solutions for this journey reside in the core domain, the business analysis focal point.
The retailer wants customer relationship management (CRM) to support the customer journey and meet the anticipated demand. It chooses Salesforce so it can continuously improve the customer journey. It also needs a content management system for its digital assets. These solutions reside in supporting subdomains.
The retailer wants to automate system administration as much as possible. The business analyst evaluates tools like Copado to meet this requirement. It falls in the generic subdomain.
Business analysts steer as many requirements as possible into the generic and supporting subdomains, focusing customization on the core domain. Yet, the supporting subdomains need to provide enough flexibility for inevitable changes in the core domain.
Applying Domain Concepts to Business Analysis
Business analysts can apply domain-driven design concepts with these steps:
Define domains before discovery. They’re usually obvious, based on the organization’s departments or areas of expertise.
Determine the core domain to contain strategic, differentiating requirements.
Look for subdomains emerging through domain experts or workgroups.
Define concepts for each domain through discovery. Different domains may define terms differently. For example, Marketing could define “lead” differently than Sales.
Map out high-level business processes before starting the data model.
Group high-level processes and their subprocesses into domains. Subdomains could emerge from subprocesses.
Create a data model only after all domains and subdomains are well-defined.
For example, the retailer’s customer journey has three high-level steps:
Raise customer awareness
Customers purchase products and services
Sustain a valuable customer relationship
The table below shows how subdomain types support each step.
The retailer creates custom solutions for the customer journey. Salesforce cloud solutions support the customer journey. All subdomains need analytics and system administration residing in the generic subdomain.
“We Already Do This!”
Experienced business analysts could read this and say, “We already break down business complexity into problem spaces - we just don’t call them domains.” Domain-driven business analysis offers more: it applies subdomain types to guide “make/buy” and other customization decisions.
For Development Team Eyes Only
Business analysts applying these concepts should avoid using terms like “domain” and “subdomain” with business stakeholders. Using the retail example above, they would simply refer to domains and subdomains by their names: “the customer journey,” sales, marketing, etc. A fundamental principle in domain-driven design is to use the organization’s language and avoid using technical terms.
Some business analysts may work with development teams who have adopted domain-driven design. Team members may ask about “ubiquitous language” or “bounded contexts,” essential aspects of domain-driven design. Ubiquitous language refers to business terms or concepts in the context of a domain. A glossary should define these terms for each domain. Ideally, a concept map would show relationships between the terms.
“Bounded context” applies to domain-driven design downstream from business analysis, intending to isolate domains from each other in implementation. This isolation is unnecessary during discovery, which often turns up integrations between domains that business analysts need to capture and refine as requirements.
The Bottom Line
Good business analysis starts with breaking down business complexity along organizational lines. Whether you break down the complexity into domains, problem spaces, or something else doesn’t matter as much as focusing customization on the parts that make the business competitive. This means solving general problems with highly configurable existing solutions, giving the development team space to build a unique, valuable solution.
Domains, subdomains, and their types can focus the development process on what matters most to an organization.
If you’re interested in how domain-driven design works with Salesforce in the architecture stage, see Denis Krizanovic’s article Applying Domain-Driven Design with Salesforce.