System Design Cases
DDD Strategic: bounded contexts and context maps
DDD Strategic Design — bounded contexts (Sales, Billing, Shipping), Generic subdomains (Auth0 conformist, SendGrid), Legacy CRM with ACL. Context map shows Customer/Supplier, Published Language, Conformist, ACL relationships. Scenarios: cross-context Customer flow (Lead -> Payer -> Recipient), ACL protecting against legacy XML, Conformist trade-off, anti-pattern microservice-per-table.
Strategic DDD: language, bounded contexts and context maps
Strategic DDD помогает обнаруживать границы моделей и команд. Bounded Context — это граница применимости языка и модели; она может совпасть с deployable unit, но не обязана быть микросервисом. Context Map фиксирует отношения и перевод между моделями, а не обещает автоматическую организационную независимость.
Что утверждает паттерн — и чего он не гарантирует
- Evans определяет Bounded Context как явную границу применимости модели; это modelling boundary, а не гарантия отдельного process/deployment.
- Ubiquitous Language должна быть точной внутри context и развиваться вместе с моделью и разговорами domain experts.
- Context Map описывает реальные отношения contexts: Customer/Supplier, Conformist, Anti-Corruption Layer, Published Language, Shared Kernel и другие trade-offs.
- Внешний subject/issuer — integration identity. Решение использовать его как domain identity требует отдельного решения и migration analysis.
Границы и компоненты
| Компонент | Ответственность |
|---|---|
| Customer Channel | Отправляет user intent и внешний identity credential. |
| Identity Anti-Corruption Layer | Проверяет issuer/subject и отображает внешний principal во внутренний CustomerId. |
| Sales Bounded Context | Владеет Sales language, model, rules и командой. |
| Sales Model Store | Хранит внутренние Sales identities и состояние модели. |
| Published Integration Contract | Версионирует значения, события и compatibility policy между contexts. |
| Billing Bounded Context | Переводит published language в Billing model. |
| Fulfillment Bounded Context | Переводит published language в fulfillment concepts. |
| Context Map and Ownership | Фиксирует upstream/downstream, ACL, shared-kernel и team ownership decisions. |
Сценарии
Discover a language boundary
Domain experts and builders find that Customer and Order carry different rules in Sales and Billing; the context map records both models instead of forcing one enterprise object.
Проверяемый исход: The same word may have context-qualified meaning, owner and invariant; ambiguity becomes an explicit hotspot.
Map external identity safely
A verified issuer/subject pair enters the ACL. It resolves or provisions an internal CustomerId; vendor identifiers never become the Sales aggregate primary key by accident.
Проверяемый исход: A provider migration changes the adapter/mapping, not every domain identity and foreign key.
Publish an integration language
Sales commits its model and emits a versioned integration fact. Billing and Fulfillment consume through their own translations rather than sharing the Sales object graph or tables.
Проверяемый исход: Consumers can evolve their internal models while the published contract remains compatible or explicitly versions.
Change a boundary deliberately
A policy change affects Sales but not Billing semantics. Teams update context-map ownership and contract version, then migrate downstream translations with telemetry.
Проверяемый исход: A boundary refactor is an explicit socio-technical migration, not a zero-cost rename or automatic service split.
Failure, concurrency и evolution checklist
- Версионировать published language и измерять consumer usage до удаления версии.
- Не давать двум contexts совместно изменять одну таблицу без явно принятого shared ownership.
- Для Shared Kernel фиксировать маленькую поверхность и совместный change protocol.
- Проверять identity mapping на account merge, provider migration и recycled/external identifiers.
Метрики, units и допущения
- Количество contexts нельзя выводить из размера команды или RPS; это результат различий языка, модели, change cadence и ownership.
- Integration SLO измеряется отдельно: publish lag, consumer lag, incompatible-message rate и reconciliation age с единицами.
- Стоимость Shared Kernel оценивается частотой совместных изменений и coordination lead time, а не объявляется всегда плохой или всегда дешёвой.
Числа здесь — размерностные формулы или явно помеченные учебные inputs. Паттерн архитектуры сам по себе не задаёт SLA, throughput, latency или fault tolerance.
Связанные темы
Первичные источники
- https://www.domainlanguage.com/ddd/reference/
- https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
- https://www.pearson.com/en-us/subject-catalog/p/implementing-domain-driven-design/P200000009616/9780321834577
Scope note
Диаграмма показывает discovery, ownership и translation boundaries. Она не утверждает, что DDD автоматически выбирает org chart, service count, database-per-service или delivery process.