In Domain-Driven Design (DDD), strategic thinking refers to the high-level planning and decision-making that shapes the overall architecture of the software system. It involves considering the bigger picture, making crucial choices about how to model and organise the domain, and ensuring the resulting design aligns with the business goals and future needs.
The Essence of Strategic thinking in DDD
At its core, strategic thinking in DDD focuses on the big picture. It begins with understanding the core domain, its key concepts and challenges. translating that knowledge into a well-defined architecture. Core domain is primarily the business domain.
1. Business Domain vs Subdomain
A Business domain defines companies main area of activity however a company can operate in multiple business domain a good example for this is Uber which is into rides-haring as well as food Delivery service. To achieve business goals, company has to operate in multiple subdomains. Subdomains is a subpart of business domain that can be seen as logical break up of entire Business domain. There are 3 types of Subdomains
- Core subdomain: It is the Foundational element that drives it success and differentiates itself from competitors and add unique value.
- Supporting subdomain: Refers to areas of the business domain that provide auxiliary or supporting functions but are not considered core or differentiating.
- Generic subdomain: All business activities that involves standard and widely accepted practices. These are areas where the business may not seek to stand out but needs to address common functionalities shared with other organizations in the industry.
Image below will demonstrate a zoom in view into Origination subdomain
2. Bounded Context
A bounded context is a central concept that helps manage complexity and promotes modularity in software development. A Bounded context should align with a single sub domain. A bounded context has it own ubiquitous language. A bounded context should be autonomous, cohesive, and loosely coupled with other bounded contexts.
Identifying bounded contexts is not a simple task; it requires a deep understanding of the domain and the business requirements of your system, as well as collaboration and communication with stakeholders, domain experts, and developers. To aid in this process, there are some techniques and heuristics that can be used, such as domain events, context mapping, business capabilities, and user stories.
3. Context Map
Now that we have defined the subdomains within its bounded context, they need to integrate. This integration is know as context mapping. A context map serves as a visual representation of the relationships between different bounded contexts.
A context can be both and Upstream context and a Downstream context at a same time, as this depends on where you stand.
When we talk about Context Mapping, question is what kind of inter-team relationship and integration is represented between the 2 bounded context. A well defined boundaries and contract between them will help support controlled changes over time. Below is the summary of different types of relationship and integrations
- Partnership: It is relationship between two teams. Two contexts collaborate closely, sharing ownership of certain domain concepts (e.g., Product Management and Order Processing working together on product catalogs). May not be a good fit for geographically distributed teams as it may present synchronisation and communication challenges.
- Shared Kernel: Represents a relationship between two or more teams that share a small but common model. Changes to the shared kernel affect both contexts, requiring close coordination.
- Customer-Supplier: Describes a relationship where one Bounded Context (the customer is downstream) depends on (the supplier is upstream) for certain functionality or information.
- Conformist: This exist when upstream team has no motivation to support the needs of the downstream team. The Downstream system conforms to the upstream bounded context’s model
- Anti-Corruption Layer: Represents a protective layer that shields one Bounded Context from the complexities of another. It is considered most defensive relationship as Downstream team creates a translation layer that isolates the downstream model from the upstream model and translates between the two .e.g. an adapter layer
- Open host Service: This can be seen as reversal of anti-corruption layer pattern .i.e. instead of consumer, the supplier implements the translation of its internal model. An open host service defines a protocal or interface which is “open” to consumers who need to integrate with the Supplier bounded context.
Conclusion
For me personally, strategic domain-driven design requires deep understanding of the problem we are trying to solve. It requires an art of solving problems that are too big for any one person or organisation to solve on their own. We need to work in colloboration with others, bringing together different perspectives and skillsets to create innovative solutions .
Reference
- Domain driven design distilled – Vaughn Vernon
- Learning Domain Driven Design – Vlad Khononov