Стратегический DDD отвечает не на вопрос «как написать код», а на более важный вопрос: как правильно разложить предметную область.
Стратегический DDD помогает:
1. Выделить ключевые бизнес-домены и понять, где находится основная ценность продукта
2. Найти границы контекстов: где одна модель заканчивается, а другая начинается
3. Определить язык, на котором бизнес и разработка говорят об одних и тех же вещах
4. Понять, какие части системы стоит разделять, а какие лучше не дробить преждевременно
Стратегический DDD помогает найти границы будущих модулей: не технических, а бизнес-смысловых.
Пример из мира 1С: «Работа с файлами», «Печать», «Пользователи», «ОбщегоНазначения» — это техническая нарезка.
Она отвечает на вопрос: «какой механизм мы используем?»
А стратегический DDD предлагает другой вопрос: «в каком бизнес-контексте это живет?»
Один и тот же присоединенный файл технически остается файлом. Но в продажах это договор с клиентом, в бухгалтерии — первичный документ, в закупках — сертификат поставщика, в сервисе — фото дефекта.
Механизм может быть общим.
Но бизнес-смысл и правила должны жить внутри своих контекстов.
Тактический DDD — это уже про конкретные строительные блоки: Entity, Value Object, Aggregate, Repository, Domain Service и так далее. Про тактический уровень поговорим позже.
А пока предлагаю простое упражнение.
Возьмите техническое задание, описание продукта или большой кусок кода и отправьте его в ChatGPT с промптом:
Выступи как архитектор программного обеспечения. Проанализируй это через призму стратегического DDD. Выдели возможные домены, bounded contexts, ключевые бизнес-понятия и зоны, где модель может быть размыта или неправильно разделена. Дай архитектурный вердикт и рекомендации.
Делитесь в комментариях: узнали ли вы что-то новое после анализа.