Managing Business Complexity with Domains
Customer Service vs. “The System”
How often have you dealt with a customer service representative who said something like:
“We can’t do [what you need] in our system.”
“I’d like to help you, but the system won’t let me.”
“The system” designed to help service representatives became a customer satisfaction obstacle. Perhaps the developers didn’t consider exceptions and other scenarios away from the “happy path.” Experienced representatives and managers probably knew about the cases, but no one asked them or informed the developers.
In other cases, building a solution to manage so many scenarios and exceptions seems too daunting, leaving users, like customer service representatives, to pick up the slack.
Domain-Driven Software Design
Business complexity arises as businesses develop new and sophisticated processes.
Software developer Eric Evans came up with domain-driven design in the early 2000s to solve complex business problems. He started by organizing development around business contexts known as domains, each with specific concepts and domain experts. Then, he created subdomains to break down complexity and model specific business operations.
Eric took on a business analyst role, working closely with domain experts to define each domain’s terminology rigorously and communicate with domain experts only in those terms.
Domains and subdomains define a solution’s context, as shown below:
Domains in the Salesforce Cloud
While “domain” sounds like a daunting mathematical term, businesses often organize them around departments or groups. For example, Salesforce developed a solution in each customer relationship management domain.
| Domain | Salesforce Solution |
|---|---|
| Marketing | Marketing Cloud |
| Sales | Sales Cloud |
| Customer Service | Service Cloud |
Note that these domains are different from Salesforce’s “My Domain” used in organization URLs.
Salesforce also offers products and features in subdomains:
| Domain | Subdomain | Salesforce Feature |
|---|---|---|
| Marketing | Advertising | Advertising Studio |
| Marketing | Email Marketing | Email Studio |
| Marketing | Social Media Management | Social Studio |
| Sales | Configure, Price and Quote | Salesforce CPQ |
| Sales | Analytics | Sales Cloud Einstein |
| Customer Service | Case Management | Advanced Case Management |
| Customer Service | Analytics | Service Analytics App |
Domains for Business Analysis
This diagram shows domain relationships in the context of an organization and its stakeholders.
The discovery of business needs focuses on one domain at a time, except where two or more overlap. For example, marketing specialists participate in marketing discovery, while sales solution involves sales experts. Overlaps like lead management and analytics would involve managers from marketing and sales or perhaps cross-domain experts.
Discovery often reveals subdomain experts, providing even more focus. For example, marketing has advertising, social media, and product marketing managers. Discovery could drill down to their specific needs, resulting in more detailed and complete requirements.
Organizing discovery and requirements around domains and subdomains guide architects and developers to shape solutions around the business. It’s better than building a “system” that may not do what the company and its customers need.
Breaking down business complexity with domains and subdomains enables more focused discovery and solution development that better fits business needs.