In the previous article, we delved into the fundamentals of Strategic Design in Domain Driven Design (DDD). In this continuation, we will explore key aspects of Strategic Design, including the decomposition of complex domains into subdomains, the importance of establishing a shared language between domain experts and software engineers, and the value of identifying context maps within our system. By grasping the essence of these strategic design concepts, we can align software development with business objectives and ensure the creation of the right software, right from the start.

Decomposing Complex Domains into Subdomains:

When dealing with a complex domain, it is crucial to break it down into manageable parts known as subdomains. This decomposition serves a twofold purpose: it not only allows us to focus on specific areas of expertise but also significantly reduces cognitive load. Complex problems can overwhelm our cognitive capabilities, making it challenging to comprehend and address the entire domain at once. However, by breaking it down into smaller, well-defined subdomains, we effectively lighten the cognitive load on both domain experts and software engineers. Each subdomain can be examined, understood, and addressed independently, fostering a clearer understanding of the domain as a whole.

The Importance of Categorizing Subdomains:

While decomposing a domain, it is helpful to categorize subdomains into three distinct categories: Core, Supporting, and Generic.

• Core subdomain: Represent the heart of the business, holding the most critical and differentiating functionalities.

• Supporting subdomain: Provide auxiliary services and functionality that enhance the Core subdomain.

• Generic subdomain: Encompass universal functionalities that are commonly found across various domains.

Categorizing subdomains have several advantages:

• Strategic advantage: By emphasizing the core subdomain, we can prioritize the development of features that differentiate your application from competitors, providing a strategic advantage in the market.

• Resource allocation: By categorizing subdomains, we can strategically assign expert developers to the core subdomain, which holds the highest value for our business. The core subdomain typically encapsulates the most critical and differentiating functionalities of the system. By dedicating our most experienced and knowledgeable developers to this area, we ensure that the core functionalities are designed and implemented with utmost precision and efficiency. Expert developers possess the domain-specific expertise and technical acumen necessary to tackle the complexities associated with the core subdomain, resulting in a higher probability of success and a greater impact on the overall system.

• Possibility of using existing solutions: Categorizing subdomains as generic enables us to leverage existing solutions and frameworks that cater to universal functionalities found across various domains. This allows us to benefit from pre-existing implementations, established best practices, and well-tested components. By adopting existing solutions, we can save time and effort, allowing our development teams to allocate more resources to the core subdomain, where complex engineering solutions may be required.

Building a Shared Language:

One of the challenges in software development projects lies in effective communication between domain experts and software engineers. Often, these two groups speak different languages, leading to misunderstandings and a mismatch between requirements and implementation. To address this, Strategic Design emphasizes the creation of a shared language known as the Ubiquitous Language. This language bridges the gap between domain experts and engineers, enabling a common understanding of the domain concepts and facilitating smooth collaboration.

Let’s explore the challenge of language disparity between software engineers and business stakeholders in more detail. When working on a healthcare system development project, it is common for software engineers to utilize technical jargon, while domain experts, such as doctors and administrators, communicate using business terms. This language gap can lead to misinterpretations and hinder effective collaboration.

For example, software engineers might refer to a particular functionality as a “data model,” whereas domain experts might describe it as a “patient record.” Without establishing a shared language, confusion and misalignment may arise, jeopardizing the accurate implementation of the healthcare system. To address this issue, the concept of Ubiquitous Language comes into play. Ubiquitous Language emphasizes the creation of a shared vocabulary that bridges the gap between software engineers and domain experts. It encourages both parties to collaborate and agree on precise definitions for key terms, enabling clear and unambiguous communication. By establishing a shared language, software engineers gain a deeper understanding of the healthcare domain and its specific terminology. This comprehension empowers them to translate complex technical concepts into meaningful and relevant business terms. Simultaneously, domain experts become familiar with essential technical terminology, enhancing their ability to effectively communicate their requirements and expectations to the software engineers. Through the adoption of a shared language, the software development process becomes more streamlined and efficient. Misunderstandings are minimized, and the chances of developing software that accurately aligns with the domain’s intent significantly increase. The shared language fosters effective communication, ensuring that software engineers and domain experts are on the same page throughout the development journey.

The Importance of Context Maps

Within a complex system, interactions between subdomains and bounded contexts can become intricate. This is where context maps come into play. A context map is a visual representation of the relationships and boundaries between different parts of the system. By identifying these relationships, we gain insight into the system’s overall structure and can anticipate potential integration challenges or conflicts.

Context maps are essential for maintaining the integrity of the system and enabling efficient collaboration between teams working on different subdomains. They provide a high-level overview of the system’s boundaries and help define clear communication channels and integration points, reducing ambiguity and fostering a cohesive and well-orchestrated architecture. Context map can be useful in different areas include:

• Planning: By examining the context map, product owners and stakeholders gain insights into the dependencies and relationships between teams. This knowledge allows them to identify potential bottlenecks, risks, and areas of potential failure. For example, if Team A is responsible for a core subdomain, and Team B, an external vendor, is responsible for a supporting subdomain that relies heavily on Team A’s outputs, any delay or miscommunication between these teams can jeopardize the overall product timeline and success.

• Risk management: The context map acts as a risk mitigation tool by highlighting such dependencies and potential points of failure. It enables product owners to proactively address risks by fostering effective communication channels, establishing clear expectations, and ensuring collaboration between teams. By identifying and addressing these risks early on, the product team can take appropriate measures to prevent potential delays, misunderstandings, and overall product failure.

• Resource allocation: It provides a clear overview of the interdependencies between teams, enabling product owners and technical leads to allocate resources effectively and prioritize tasks based on critical dependencies. For instance, if a core subdomain requires significant development effort and multiple supporting subdomains are reliant on it, the product team can allocate more resources and prioritize development efforts accordingly, ensuring that critical areas receive the necessary attention and reducing the risk of product delays or failures.

Conclusion

Strategic Design in DDD encompasses various vital elements that contribute to the success of software development projects. By decomposing complex domains into subdomains, categorizing them appropriately, establishing a shared language, and identifying context maps, we create a solid foundation for effective collaboration, clear communication, and the development of robust and maintainable software systems. Embracing these strategic design principles can greatly enhance our chances of achieving success in DDD projects, enabling us to build software that aligns seamlessly with the domain’s objectives and requirements.