Domain-Driven Design

Бизнес и разработка должны говорить на одном языке. И это НЕ язык разработки.

Если для бизнеса

‍«Контейнер», «Политика загрузки контейнеров», «Политика перевозки контейнеров» — отдельные сущности...

В разработке не нужно объединять эти сущности внутрь одного класса. На уровне кода они должны быть разделены так же, как и в бизнесе.

‍

Если у бизнеса

‍иерархия

• Товары

• Автомобили

• Запчасти

В разработке неправильно выстраивать иерархию так:

• Товары

• Технические изделия

• Автомобили

• Запчасти

Правильная иерархия в разработке полностью совпадает с иерархией бизнеса:

• Товары

• Автомобили

• Запчасти

‍

Если у бизнеса в БП «Заказ»

есть действие «Передача данных о заказе».

В разработке оно не должно называться «Создание новой темы в топике»

Правильный нейминг: «Передача данных о заказе».

‍

Если не придерживаться DDD

• бизнес концентрируется на техническом языке — не «что и зачем», а «как», и разработчики с большей вероятностью превращаются в простых исполнителей;

• разработчики тратят время не на доставку ценности, а на преодоление технических сложностей;

• ценности в целом описываются хуже, эффект от проекта становится менее заметным, что приводит к выгоранию команды и заказчика.

‍

Подробнее о DDD

‍