Domain-Driven Design

Domain-Driven Design

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

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

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

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

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

иерархия

  • Товары
  • Автомобили
  • Запчасти

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

  • Товары
  • Технические изделия
  • Автомобили
  • Запчасти

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

  • Товары
  • Автомобили
  • Запчасти

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

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

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

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

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

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

Подробнее о DDD

Другие статьи

Смотреть все

Что такое техническая поддержка и почему она должна быть не на разработчике

Читать

Тестирование

Читать

Ретроспектива прошлого года в проекте

Читать

Ваша заявка отправлена успешно

Отправить снова

Базовый курс управления и построения IT-контура компании. Поток 05.09.23

Контакты

С вами свяжется модератор курса Алексей Клоков