DDD + AI-агенты: почему доменная модель стала важнее кода
Когда добавляешь AI-агентов в разработку, Domain-Driven Design перестаёт быть "теоретической концепцией для энтерпрайза" и становится практической необходимостью
Вот что я заметил на практике:
Агент не понимает бизнес-логику — только структуру Claude Code и Cursor видят код. Они не знают, почему Order и Invoice — это разные агрегаты, даже если технически похожи. Без явной доменной модели агент генерирует технически корректный код, который нарушает бизнес-инварианты.
Bounded Context = граница ответственности агента Когда контекст чётко очерчен (User Management, Billing, Notifications — разные модули), агент не "утекает" логикой через границы. Это снижает количество противоречивых решений в разных частях системы.
Ubiquitous Language в CLAUDE.md Добавил в CLAUDE.md словарь домена: что такое "заказ" в нашем контексте, чем "клиент" отличается от "пользователя". Агент перестал путаться и начал использовать правильные термины везде — в коде, в тестах, в именах методов.
Результат: код стал более предсказуемым, меньше правок после ревью, агент "думает" на языке бизнеса.
DDD — это не overhead. Это способ передать агенту понимание, которое иначе он просто не может получить.
Используете DDD в своих проектах? Как это взаимодействует с AI-инструментами?
· 18.04
Владимир, рад что зашло! Для вайбкодинга это особенно актуально — чем быстрее генерируешь код, тем важнее иметь чёткие границы где агент "играет". Иначе скорость работает против тебя: быстро нагенерил, а потом долго разгребаешь противоречия между модулями. DDD даёт эти границы.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён