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.

Границы и компоненты

Сценарии

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.

Связанные темы

[CONCEPT]ddd-tactical

[CONCEPT]event-storming

Первичные источники

• 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.