(Sub) Domain vs. Bounded Context II – Explained on the Simple Case of E-Mail

In our last article on the contrarian discussion about '(Sub) Domain vs. Bounded Context', we looked at the strategic slicing of domains and bounded contexts using Domain-Driven Design (DDD) principles. We explored methods such as Wardley Mapping and the Business Model Canvas to determine the appropriate slices for (sub)domains. Now let's deepen our understanding with a concrete example to illustrate different slicing strategies. Specifically, we'll examine how an online store handles email communication, focusing on the decision between a centralized email system and a decentralized approach.

The Context: Sending Emails in an Online Store

Emails in an online store can be categorized into two main types (for simplicity's sake):

1. Transactional Emails: These are triggered by customer actions, such as order confirmations, shipping notifications, and password resets.
2. Newsletters: Promotional emails are sent periodically to keep customers engaged and informed about offers, new products, or company news.

To keep our discussion manageable, we'll explore two distinct approaches:

1. Centralized Email System: A single system handles all email communications.
2. Decentralized Email Systems: Separate systems handle emails based on the context in which they are sent.

Centralized Email System

The centralization approach is based on the idea that sending email is fundamentally a technical challenge that remains consistent regardless of the type of email. Therefore, consolidating the email-sending functionality into one system (or bounded context) is seen as more efficient. The system can handle all types of email, and new types can be added relatively easily, leveraging existing infrastructure.

The Flaws in Centralization

However, this seemingly efficient solution contains significant misconceptions. The technical act of sending an email is not the primary challenge. The real complexity lies in the intent:

• When the email should be sent.
• To whom the email should be sent.
• Which content should be included in the email.

If these decisions are made within the centralized email system, it would be necessary to incorporate a wide range of contextual information from different parts of the organization. The result is an overly complex system that is difficult to maintain and evolve.

To mitigate this, one might suggest developing a more abstract general API for sending email. This API would allow other systems to specify timing, recipients, and content. But if we go this route, why not use a cloud email provider like SendGrid that already offers such an API?

Managing Specific Requirements

One might argue that a centralized service is needed to manage certain requirements, such as ensuring that a recipient has consented to receive certain types of email, or deciding whether to send an SMS instead of an email. But this can be done without centralization.

Decentralized Email Systems

A more contextual approach uses the business model to determine the impact of email use cases on different parts of the business. For example, transactional email relates to the channel building block, while newsletters relate to the customer relationship management (CRM) building block.

Identifying (Sub)Domains

By considering the business impact, we can identify distinct (sub)domains for different email types:

• Transactional Emails: These could belong to the "Buying Domain," as they are directly tied to the customer's purchasing actions.
• Newsletters: These could fall within the "Care Domain," as they are aimed at maintaining customer engagement post-purchase.

The result is two separate services, each managed by different teams focused on their specific domain. Each team can use cloud email providers for the actual sending of email, allowing them to focus on domain-specific logic.

Advantages of Decentralization

1. Domain-Specific Focus: Teams can focus on the unique requirements and context of their domain, leading to more tailored and effective solutions.
2. Reduced Complexity: Each service remains simpler and more maintainable, as it only deals with its specific type of email.
3. Leverage Cloud Services: By using cloud providers for email sending, teams avoid reinventing the wheel and can rely on robust, scalable solutions.

Handling Additional Requirements

A third service can be used to manage email frequency, channel preferences (e.g., email or SMS), and consent. This service maintains customer preference and consent information that can be asynchronously replicated to other services. Alternatively, a thin platform service could be designed as an abstraction in front of the cloud service (e.g. SendGrid) to handle email scheduling and prioritization based on user profiles and consent.

Conclusion

The choice between centralized and decentralized email systems illustrates the broader principles of DDD in action. While centralization may seem efficient, it often leads to higher complexity and maintenance challenges. Decentralization, driven by the business model and domain-specific contexts, offers a more sustainable and efficient approach. By focusing on domain-specific needs and leveraging existing cloud services, teams can build robust, maintainable systems that more easily adapt to evolving requirements.

In our next article, we'll take a closer look at identifying specific (sub)domains within the business model and exploring how these domains interact to create a cohesive system. Stay tuned for a detailed examination of domain identification and its implications for efficient system design.

In the meantime, feel free to roam around our other tech-focused content in our Insights section.