📚 Что такое пост-документация в DDD?

Все, финальная часть про DDD.
Весь путь: про стейкхолдеров и бизнес, про проектирование, про разработку, про тестирование.

Это не только «техописания» и не столько API.
Это — фиксация моделей, бизнес-решений, контекстов и ограничений, с которыми вы проектировали и кодили.
И важно: такая документация пишется в процессе работы, а финализируется не по окончании проекта, а когда принято финальное решение, позволяющее ее финализировать.

1. Зачем вообще она нужна?
📉 Модели теряются. Через 6 месяцев никто не помнит, почему Transaction и Adjustment — это два разных агрегата.
💬 Команда меняется. Новичкам сложно въехать в неочевидные решения.
🧩 Интеграции множатся. Без явной документации контексты путаются, границы стираются, начинается ад из «просто использовали не по назначению чужую сущность».
🤒 Клиенты (любых видов) не должны страдать. А значит им нужна своевременная и понятная документация на их языке.

2. Что фиксируем:
Bounded Context-ы:
— их границы, название, бизнес-смысл
— где их API, с кем они взаимодействуют
Ubiquitous Language:
— глоссарий терминов
— амбигуозности
— кто как называет “клиента” и “транзакцию” — и почему
Доменные модели:
— диаграммы (в т.ч. Event Storming)
— паттерны, которые вы внедрили
— архитектурные компромиссы, которые пришлось принять
Бизнес-решения:
— почему поведение системы именно такое
— какая гипотеза лежала в основе
— что было сделано «временным решением» (и когда его пересматривать)

3. В чем особенность DDD-документации:
Она пишется на языке бизнеса, а не только техническом.
Она живет рядом с кодом — в wiki, в ADR-нотах, в репозиториях, а не в спрятанных PDF.
Она строится по мере развития модели, а не «в конце проекта».

4. А в чем сложность?
– Нужен тот, кто будет ее писать! Бизнес считает, что документация — дело разработчиков. Разработчики считают, что это «долго и не нужно».
– Стоимость! Никто не хочет платить за «ничего» — а ведь пост-документация и есть ваш антидолг. Она сохраняет знания, которые иначе потеряются.
В DDD документация логично завершает каждый виток моделирования.

Отдельно про финтех: Финансовые организации зачастую должны готовить документацию для регуляторов или партнеров. DDD здесь – палочка-выручалочка, потому что наличие четкой модели и терминологии позволяет сравнительно легко написать необходимые описания. Например, для сертификации PCI DSS может потребоваться описать потоки данных карточных транзакций – команда, имея на руках контекстную диаграмму и описание событий, подготовит такой документ быстрее.

#architecture #ddd