Всем привет!
Сегодня хочу коснуться такого понятия Domain Driven Design как модель. В подходе DDD мы говорим о моделировании бизнес-процессов в коде системы. Существуют различные мнения и заблуждения на этот счет. Давайте разберемся, а что же, по своей сути, называется моделью.
Что такое модель?
Модель — это ограниченное и упрощенное представление реального объекта или явления. Которое сохраняет те свойства оригинала, которые важны для исследования.
Модель —это представление в воображении, в виде математических, физических, графических или символических форм.
То есть, когда мы говорим о моделировании в DDD, мы говорим о выражении определенных свойств (важных в данной предметной области) бизнес-процессов и объектов через доступные нам формы:
- кода разработчиков;
- диаграмм и описаний архитекторов;
- документации системных и бизнес-аналитиков;
- мыслей и описания процессов бизнес-заказчиков.
Что не так с моделями?
Здесь важно понимать, что каждая модель является упрощенным представлением сложного процесса. И когда между разработчиком и заказчиком нет прямой коммуникации, а передача знаний осуществляется по цепочке — от бизнеса к аналитикам, от аналитиков к разработчикам, тогда неизбежно на каждом шаге передачи знаний возникает свое упрощение или усложнение модели. Другими словами, каждый следующий участник моделирования начинает строить свою модель на основе переданной ему.
В таких случаях велика вероятность потерять важные свойства модели, важные для бизнеса. И тогда возникают ситуации, что система работает совсем не так, как этого хочет заказчик. Как говорил итальянский программист Альберто Брандолини (создатель подхода Event Storming): «В прод идут не знания экспертов в предметной области, а предположения разработчиков».
Точность и применимость модели
Важно создавать модель, которая была бы максимально проста и при этом обладала всеми характеристиками, которые нужны для описания процесса. Модель не должна учитывать все свойства, которые есть у рассматриваемого процесса, а только строго необходимые для моделирования.
В качестве примера можно обратиться к моделям в физике (мне это ближе, как физику в прошлом) — теория гравитации Ньютона и теория гравитации Эйнштейна. Безусловно, теория Эйнштейна более точна и описывает явления, которые не может описать теория гравитации Ньютона (гравитационное линзирование света, замедление времени). Но для большинства задач, таких как построение зданий, конструирование авиатехники и судов, нас полностью устраивает точность модели Ньютона. Да и использование теории Ньютона значительно проще.
И еще одно из важных свойств модели — ее применимость к текущей задаче. В примере с теориями гравитации мы не используем общую теорию относительности для расчетов везде, а только для определенных задач космологии - процессов в галактиках и вселенной.
Как пример из жизни — заказ в интернет-магазине. Для целей логистики модель должна содержать данные для логистики — вес, габариты, пункт отправления и пункт назначения и т.д. А для финансовой отчетности, скорее всего не понадобятся ни габариты, ни вес.
Нет единственно верной модели для всей организации. В DDD мы признаем это и создаем разные модели для разных контекстов.
Как создавать модели?
Создание модели — это сложный процесс поиска компромиссов между простотой реализации и выбором необходимых свойств для описания процесса и/или объекта.
Подключайте представителей бизнеса к обсуждению и моделированию. Старайтесь понять модели в их голове. Исключите "испорченный телефон".
Начните с минимального количества свойств, а если их не хватает, то добавьте. Действуйте итерациями, уточняя модель, если это необходимо.
Это снизит риск несовпадения модели в голове бизнеса и модели в коде.
Какие инструменты вы используете для синхронизации моделей между бизнесом и разработкой? Пишите в комментариях!
Подписывайтесь на мой канал в telegram
#DDD #DomainDrivenDesign #model #theory