戦略的設計とコンテキストマッピング

Domain-Driven Design (DDD) isn't just about writing code! Strategic Design helps us understand the large-scale structure of our system. It's about identifying core business domains and how they interact.

This high-level view is crucial for building complex, maintainable, and scalable SaaS applications.

Remember Bounded Contexts from previous lessons? They define clear boundaries for distinct parts of your domain, each with its own language and model.

But what happens when different contexts need to communicate? That's where strategic design patterns come into play to manage these interactions.

Context Mapping is the process of identifying and visualizing the relationships between your Bounded Contexts. It helps teams:

• Understand dependencies.
• Manage integration points.
• Choose the right collaboration patterns.

It's like drawing a map of your entire system's domain interactions.

A Shared Kernel is a small, agreed-upon subset of the domain model that is shared by two or more Bounded Contexts. This means the teams working on these contexts must coordinate changes to this shared code.

• Pros: Reduces duplication, ensures consistency for core concepts.
• Cons: Creates tight coupling, changes require significant coordination.

Best for: Very stable, core concepts that rarely change (e.g., a common 'User ID' or 'Product SKU').

In a Customer/Supplier relationship, one Bounded Context (the 'Customer') explicitly depends on another (the 'Supplier'). The Supplier commits to meeting the Customer's needs.

• Upstream: The Supplier context, producing data or services.
• Downstream: The Customer context, consuming data or services.

Best for: Internal service integrations where the supplier team has an incentive to support the customer's requirements.

A Conformist relationship means the Downstream context simply adopts the Upstream's model and language, even if it's not perfectly suited. There's no translation layer.

• Pros: Simple integration, less work for the Downstream team.
• Cons: Downstream is vulnerable to upstream changes; the model might not fit perfectly.

Best for: When the Upstream context is dominant (e.g., a third-party API) and you have no leverage to influence its design.

An Open Host Service (OHS) explicitly defines a public protocol or API for other contexts to interact with it. A Published Language (PL) is the well-documented, standardized language (e.g., JSON schema) used by the OHS.

Together, they provide a stable, documented interface for integration, much like a public API.

Best for: When you want to offer a service to many different consumers, internal or external, with a clear contract.

An Anti-Corruption Layer (ACL) acts as a translation buffer between two Bounded Contexts. It protects the Downstream context from the complexities, undesirable aspects, or legacy model of the Upstream system.

It prevents the 'corruption' of your clean domain model by an external or legacy system.

Best for: Interacting with legacy systems, third-party APIs, or a conformist upstream whose model doesn't align with your domain.

While the previous patterns are very common, others exist:

• Partnership: Two contexts with mutual dependency, requiring close coordination between teams.
• Separate Ways: Two contexts that have no relationship, solving similar problems independently (e.g., two completely different products in a suite).

Choosing the right pattern depends on team dynamics, domain complexity, and the system's evolution.

Your modern "User Profile" Bounded Context needs to integrate with a legacy user management system that has an outdated and confusing data model. You want to ensure your clean context isn't negatively impacted by the legacy system's complexities.

We've explored how Strategic Design helps manage relationships between Bounded Contexts. Understanding patterns like Shared Kernel, Customer/Supplier, Conformist, Open Host Service / Published Language, and especially the Anti-Corruption Layer, is vital.

Use Context Mapping to visualize these relationships and make informed architectural decisions for your SaaS product!