🧩 Сейчас принято говорить о Domain-Driven Design (DDD) в контексте микросервисной архитектуры. Но использование этого подхода определяется не столько желанием отправлять события и команды по сети, сколько сложностью связей бизнес-сущностей и количеством бизнес-правил.

📚 Если модель вашей предметной области занимает больше 100 диаграмм и не меньшего количества бизнес правил, то стоит начать задумываться. Разработчики могут долго смотреть на модель и придумывать варианты реализации. Если у кого-то в команде аллергия на стандартные решения, то получится велосипед без седла, зато с bounded contexts и aggregate roots. Остальные просто достанут с полки Эванса и Вернона.

🔗 Этот подход инкапсулирует бизнес логику в одном месте и поможет избавиться от ситуаций, когда она размазана тонким слоем по всем сервисам. Однозначно снизится избыточная сцепленность, а багов из серии "поменяли одну фичу - сломали другую" станет заметно меньше.

🎪 Казалось бы, договорились об определениях, распилили домен на агрегаты и пошли дальше. На практике тяжело остановиться на чистом DDD, слишком велик соблазн прикрутить CQRS, event-sourcing, саги и ещё десяток другой зверей в этом архитектурном зоопарке. Легко увлечься и переусложнить систему, оторвавшись от реальных потребностей бизнеса.

🔀 Обычно так получается, когда в команде никто не отвечает за принятие архитектурных решений. Или, что еще хуже, последнее слово остается за человеком из бизнес-блока, не обладающим достаточным уровнем компетенций. Принятие архитектурных решений размазывается по команде, разработчики начинают делать как им удобно, и это удобнее для каждого свое.

💡 На самом деле DDD - это тяжелая артиллерия в мире программирования. И если посмотреть на рынок, вакансий с этим требованием - единицы даже среди крупнейших компаний. И главный вопрос здесь не в том, умеете ли вы его применять, а в том, нужен ли он вашей системе вообще.