Продолжаю серию постов по DDD. А если пропустили, то: пост1 и пост2.
Внезапно DDD не про «сделать микросервис» или «назвать package domain».
DDD в на уровне реализации — это когда код говорит на том же языке, что и бизнес, и этот язык не ломается по дороге от требования до продакшна.
Да, та самая проекция бизнеса на код!
1. Что это дает:
🧠 Проекция модели
Главый постулат: бизнес-логика в коде = бизнес-логика в головах.
Сервис PaymentLimitChecker вместо SomeUtils.calculate() — и уже ясно, о чем речь.
📚 Код как документ
Не надо искать ТЗ или копаться в Confluence. Код читается как описание предметной области — потому что оно и есть.
А еще проще онбодинг, а вся компания на шаг ближе к обезличенному коду.
🧩 Модулярность не по слоям, а по смыслу
Если бизнес-правило живет в отдельной сущности, его легче тестировать, изменять и обсуждать.
А если вся логика в контроллере — нет ни контроля, ни логики.
2. Когда DDD мешает:
— если вы «наслоили паттернов», но никто не понимает, зачем эти ValueObject и Aggregate;
— если всt ради красоты — но бизнес до сих пор зовет кнопку «фильтр» там, где в коде OperationController.
3. Почему в DDD разработчики становятся проектировщиками?
Потому что именно они делают последние (и ключевые!) проектные решения:
— куда положить правило?
— как назвать сущность?
— разделить сущность или расширить типизацию?
Это уже архитектура, только реализованная на уровне строк кода.
DDD говорит: если ты пишешь логику — ты проектируешь. И тебе нужен язык, с которым ты можешь это делать корректно.
4. DDD != антипаттерн слоев, как и DDD != слои
Если ваша архитектура:
- слой контроллеров
- слой сервисов
- слой API
…и все это в одном Bounded Context — это еще не DDD.
Так же как и запиленный небольшой монолитик, но если он Bounded Context вполне может быть DDD.
Бизнес говорит: «нельзя переводить больше 300 000₽ в сутки».
Вы:
1) не хардкодите «300000» в 5 местах,
2) создаете TransferLimit и Policy,
3) называете метод canTransferToday(amount)
И этим создаете язык, на котором можно говорить с бизнесом — в коде.
DDD в реализации — не стиль кода. Это инструмент для мышления, который позволяет писать системы, которые будут жить, а не сползать в баги и затычки.
Завтра — про тестирование: как проверять поведение, а не строки.
💬 А у вас код с бизнесом на одном языке?
#architecture #ddd
