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-инструментами?

DDD + AI-агенты: почему доменная модель стала важнее кода | Сетка — социальная сеть от hh.ru