Я уже писала пост про почему event storming не всегда хорошая идея чтобы зайти в DDD.
Если вы решили «поиграть в DDD», начните с самого простого и самого важного: разобраться в предметной области. DDD — это не магия, не набор модных практик и не набор стикеров на стене.
С чего реально начинать:
1️⃣ Читайте законы. Они часто содержат «истину» о том, как вещи должны работать (особенно в финтехе, комплаенсе, KYC).
2️⃣ Делайте словарик терминов. Убедитесь, что слово «счет», «платеж», «операция» означает одно и то же для бизнеса, для юристов и для девов.
3️⃣ Собирайте проверяемые факты — не «чувства» и не домыслы.
☝️И самое главное — никому и ничему не верьте.
Почему? Потому что самая опасная вещь на старте — принять чью-то версию «истины» за окончательную. Если бы у вас была истина, вы бы не занимались DDD: вы бы просто поменяли процесс под истину и ВСЕ! Но вы пришли, чтобы проверять, фиксировать несоответствия и строить предкорректную модель — модель, на которой могут оперировать и бизнес, и разработка.
Что следует проверять (источники проверок):
Закон — как вещь должна работать по правилам государства. (сложнее менять)
Внутренние регламенты, политики, оферты, договоры — что официально декларировано внутри компании (проще менять, но пока действует — имеет силу).
Код и текущие реализации — как сейчас работает система на самом деле (источник реального поведения пользователей/системы).
Каждый «депозит» (слово бизнеса, кредит доверия, решение в архитектуре) требует проверки по этим источникам.Важно понимать разницу: законы тяжело переписать; договоры и оферты — гораздо проще. Поэтому приоритет проверки — закон → внутренние документы → код. Но и код нельзя считать «истиной» без проверки: иногда код — это лишь костыль, неформальная договоренность.
Практический алгоритм старта DDD:
1️⃣ Сбор первичных фактов (законы, регламенты, таблички из БД, примеры операций).
2️⃣ Составление простого словаря терминов — обсуждение и фиксирование.
3️⃣ Построение «предкорректной» доменной модели (HLD вам в помощь).
4️⃣ Проверка модели на реальных текущих примерах: боевые пользовательские сценарии (без использования ИС), законы.
🔄 Итерации: корректируем модель, снова проверяем, выстраиваем контракт между бизнесом и девами.
Про event storming:
не стартуйте с него, если вы не сделали первые три шага. Event storming — мощный инструмент, но без проверяемых фактов и без согласованного языка это всего лишь красивый брейншторм. А главное у вас должны быть доменные эксперты (а их еще и взять откуда-то надо) и эти товарищи должны уметь коллаборировать!
DDD — это не про быстрые победы. Это тот случай, когда вам нужно несколько раз «свериться с картой» и ее пофиксить, чтобы двигаться вперед. И даже не про модную аббревиатуру, а жаль! Это подход, позволяющий учиться видеть и проговаривать предметную область вместе с командой (в широком смысле этого слова).
И начинать стоит именно с простых шагов, а не с разноцветных стикеров!
Про то, как писать определения 👉 вот тут
Про то, как искать доменных экспертов 👉 вот тут
💬 А как у вас с таким подходом? Особенно откликнитесь, пжл, те, кто пишет определения!
#ddd #architecture
