Strategic Design

Gerson Sunyé gerson.sunye@univ-nantes.fr

Introduction

Strategic Design, a pillar of the Domain Driven Design

Focuses on the high-level design of the system
Involves:
- understanding the business domain
- defining bounded contexts
- mapping the relationships between them
Key Concepts:
- Bounded Contexts
- Context Mapping

chessboard

Strategic and Tactical Design

Benefits of Strategic Design

Aligns software with business goals.
Reduces complexity by separating concerns.
Enhances communication across teams.

Strategic Patterns

Figure 1. Eric Evans Strategic Patterns

Bounded Contexts

One of the most important concepts of DDD
Mainly a linguistic delimitation
Each Bounded context has its own Ubiquitous Language

Ubiquitous Language

Modeled within a Bounded context
Identifies terms and concepts of the business domain
Brings together the domain experts and the technical team

Context Maps

Help in understanding the whole project:
- show the relationships between the different Bounded Contexts
To build the domain model correctly, it is important to understand these relationships

Context Map Categorization

Context map patterns are categorized in three ways

Upstream patterns: Open Host Service and Event Publisher
Midway patterns: Shared Kernel, Published Language, Separate Ways, Partnership
Downstream patterns: Customer/Supplier, Conformist, Anti-Corruption Layer

Upstream Patterns

Figure 2. Context Map Upstream Patterns

Open Host Service: defines a protocol that gives access to the sub-system as a set of services.
Event Publisher: publishes all its domain events through an asynchronous messaging system

Open Host Service > "Define a protocol that gives access to your sub-system as a set of services. Open the protocol so that all who need to integrate with you can use it. Enhance and expand the protocol to handle new integration requirements, except when a single team has idiosyncratic needs. Then, use a one-off translator to augment the protocol for that special case so that the shared protocol can stay simple and coherent.– [Vaughn 2013]
Event Publisher >Domain events are something that happens in the domain and that is important to domain experts. An upstream context publishes all its domain events through a messaging system (preferably an asynchronous one) and downstream contexts can subscribe to the events that are relevant for them and conform or transform those events in their models (following an Access Control List (ACL)) and react accordingly.

Midway Patterns (1/2)

Figure 3. Context Map Midway Patterns

Shared Kernel: designates a subset of the domain model that the two teams agree to share.
Published Language: common language that translates models from different contexts

Midway Patterns (2/2)

Figure 4. Context Map Midway Patterns

Separate Ways: the two sets of functionality have no significant relationship
Partnership: the two contexts forge a partnership to avoid that failures in one side impact the other

Separate Ways "If two sets of functionality have no significant relationship, they can be completely cut loose from each other. Integration is always expensive, and sometimes the benefit is small. Declare a bounded context to have no connection to the others at all, enabling developers to find simple, specialized solutions within this small scope." [Vaughn 2013]
Partnership "Where development failure in either of two contexts would result in delivery failure for both, forge a partnership between the teams in charge of the two contexts. Institute a process for coordinated planning of development and joint management of integration. The teams must cooperate on the evolution of their interfaces to accommodate the development needs of both systems. Interdependent features should be scheduled so that they are completed for the same release." [Vaughn 2013]

Downstream Patterns

Figure 5. Context Map Downstream Patterns

Customer/Supplier: relationship where the upstream team may succeed interdependently of the downstream team
Conformist: relationship where the upstream has no motivation to provide for the downstream needs
Anti-Corruption Layer: more defensive map, which prevents the intrusion of foreign terms.

Customer/Supplier "When two teams are in an upstream-downstream relationship, where the upstream team may succeed interdependently of the fate of the downstream team, the needs of the downstream team come to be addressed in a variety of ways with a wide range of consequences. Downstream priorities factor into upstream planning. Negotiate and budget tasks for downstream requirements so that everyone understands the commitment and schedule." [Vaughn 2013] "The freewheeling development of the upstream team can be cramped if the downstream team has veto power over changes, or if procedures for requesting changes are too cumbersome. The upstream team may even be inhibited and worried about breaking the downstream system. Meanwhile, the downstream team can be helpless, at the mercy of upstream priorities." [Evans 2003]
Conformist "When two development teams have an upstream/downstream relationship in which the upstream has no motivation to provide for the downstream team’s needs, the downstream team is helpless. Altruism may motivate upstream developers to make promises, but they are unlikely to be fulfilled. Belief in those good intentions leads the downstream team to make plans based on features that will never be available. The downstream project will be delayed until the team ultimately learns to live with what it is given. An interface tailored to the needs of the downstream team is not on the cards." [Evans 2003] "The downstream team eliminates the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team." [Vaughn 2013]
Anti-Corruption Layer "Translation layers can be simple, even elegant, when bridging well-designed bounded contexts with cooperative teams. But when control or communication is not adequate to pull off a shared kernel, partner, or customer-supplier relationship, translation becomes more complex. The translation layer takes on a more defensive tone. As a downstream client, create an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model. This layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in one or both directions as necessary between the two models." [Vaughn 2013]

Anticorruption Layer

Anti-Corruption Layer

Set of defensive patterns between:
- Two bounded contexts
- Our domain model and third-party dependencies
Intent: prevent the intrusion of foreign concepts

Purposes

Preserves the integrity of the domain model
Encapsulates technological and technical details
Promotes loose coupling

Solution

Use a anti-corruption layer to isolate différent subsystems
This layer translates the communication between systems
- each subsystem remains the same
- the design is not corrupted

Structure

Figure 6. Anti-Corruption Layer Structure

Image from Microsoft Learn

Usage (1/)

Figure 7. Sequence Diagram representing Component Interaction

Usage (2/)

The Domain Model activates and sends a request to the Anti-Corruption Layer (ACL).
The ACL activates and uses an Adapter to translate the domain request into the format and semantics of the External System.

Usage (3/)

The Adapter activates and communicates with the External System to send the translated request.
The External System activates and processes the request, then sends back a response to the adapter.

Usage (4/)

The Adapter activates and translates the response into the format and semantics of the domain model.
The Adapter de-activates and the ACL activates, then provides the translated data to the Domain Model.

Usage (5/)

The ACL de-activates and the Domain Model activates, receiving the translated data.

Used Design Patterns

Typical Design Patterns
- Façade
- Adapter

Benefits of using an ACL

Improved maintainability

By isolating the domain model from external systems, the ACL makes it easier to maintain the domain model and adapt it to changes in the external environment.

Increased testability

The ACL allows you to test the domain model in isolation from external dependencies, making it easier to ensure its correctness.

Reduced complexity

The ACL helps to reduce the complexity of the overall system by encapsulating the interaction with external systems.

Tradeoffs

Performance Overhead

An ACL may impact response times. The additional processing introduced by the ACL can add latency to calls between the domain model and the external systems. This impact needs to be assessed and mitigated if necessary.

Consider how the ACL will scale under increased load. Ensure it can handle the expected amount of traffic without bottlenecks.

Complexity

Implementing and maintaining an ACL adds complexity to the system. It requires additional code, testing, and documentation.

Be mindful not to over-engineer the ACL by adding unnecessary layers or complexity. Keep it focused on its core purpose of isolating and protecting the domain model.

Flexibility and Adaptability

The ACL should be flexible enough to adapt to changes in the external systems without requiring significant modifications to the domain model.

The ACL should not prevent the evolution of the domain model. It should be designed to accommodate changes in domain logic and concepts.

Monitoring

Implement robust error handling mechanisms within the ACL to gracefully handle failures and exceptions.

Establish adequate logging and tracing capabilities to monitor the performance and behavior of the ACL and identify potential issues.

Testability

Design the ACL with testability in mind. This allows you to mock or stub external dependencies during testing to isolate and test specific components of the ACL.

In addition to unit and integration tests, consider implementing end-to-end tests that validate the interaction between the domain model, the ACL, and the external systems.

Security

Implement data validation and sanitization mechanisms within the ACL to protect the domain model from invalid or malicious data coming from the external systems.

Implement appropriate authorization and access control mechanisms within the ACL to control how the domain model interacts with the external systems.

Documentation

Clearly document the purpose, design, and implementation of the ACL. This documentation will help developers understand how the ACL works and how to interact with it.

Clearly define the contracts and boundaries between the domain model, the ACL, and the external systems. This will help ensure consistency and maintainability.

Conclusion

Figure 8. Pattern Mapping

Separate Ways: corresponds to bounded contexts that have no connection to others.
Single Bounded Context: is indicative of a domain that is not modularized.

Published Language: uses a well-documented and shared language that can express the necessary domain information as a common medium of communication, translating as required
Conformist: eliminates the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team

Anti-Corruption Layer: creates an isolating layer to provide clients with functionality in terms of their own domain model; the layer ks to the::other system through its existing interface, requiring little or no modification to the other system
Open Host Service: defines a protocol that gives access to your sub-system as a set of services

Event Publisher: communicates with other bounded contexts through domain events that can be consumed by other bounded contexts
Customer/Supplier: establishes a clear customer/supplier relationship between the two teams

Shared Kernel: designates some subset of the domain model that the two teams agree to share