Цифровизация бизнеса: подходы к созданию цифровой модели

В данной статье я постараюсь простыми словами рассказать об очень сложной теме - предметно-ориентированном проектировании (DDD, domain-driven design). Данный подход применяется с целью создания цифровой модели бизнеса. Я полагаю, что современным представителям бизнеса, курирующим проекты по цифровой трансформации, данная информация окажется полезной в части принятия взвешенных решений, основанных на экспертизе и лучших мировых практиках по цифровизации.

Рассмотрим основные концепции предметно-ориентированного проектирования (далее по тексту - DDD).

Идея использования единого языка заключается в стремлении употреблять в коде те же термины, что и бизнес в своей профессиональной деятельности. Наличие общего языка между командой разработки и людьми бизнеса облегчает моделирование предметной области реального мира, а также улучшает коммуникацию.

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

Под агрегатом в DDD подразумевают автономную единицу, обладающую состояниями. Например, для интернет-магазина, "заказ" - хороший пример агрегата. Жизненный цикл агрегатов связан с изменением их состояний. С точки зрения разработчиков, необходимо убедиться, что код, обрабатывающий переходы состояний агрегатов, сгруппирован с вместе с самим состоянием. Таким образом, один агрегат должен управляться одним микросервисом, хотя один микросервис может управлять несколькими агрегатами.

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

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

Здесь важно понимать, что, если внешняя сторона запрашивает переход состояния в агрегате - тот, в свою очередь, может сказать «нет». В идеале, необходимо реализовать свои алгоритмы таким образом, чтобы недопустимые переходы состоянии были невозможны.

Одни агрегаты могут взаимодействовать с другими. Эти агрегаты могут управляться одним и тем же микросервисом или разными. Если эти отношения между агрегатами существуют внутри области одного микросервиса, их можно легко сохранить, используя что-то вроде внешнего ключа (аналогия с primary key в БД). Однако, если отношения между этими агрегатами простираются за границы микросервиса, потребуется какой-то способ их моделирования.

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

С точки зрения реализации, ограниченные контексты содержат один или несколько агрегатов. Некоторые из них могут быть доступны вне ограниченного контекста, другие - скрыты внутри. Ограниченные контексты могут иметь связи с другими ограниченными контекстами - при сопоставлении с сервисами эти зависимости становятся зависимостями между сервисами.

Агрегаты и ограниченный контекст дают нам единицы связности с четко определенными интерфейсами с более широкой системой. Агрегат - это независимый конечный автомат, который фокусируется на концепции одной предметной области в нашей системе. При этом, ограниченный контекст представляет собой набор связанных агрегатов с явным интерфейсом связи с внешними потребителями.

Следовательно, и агрегаты и ограниченный контекст могут хорошо работать в качестве границ сервисов. Учтите, что агрегаты лучше не разделять - один микросервис может управлять разным количеством агрегатов, однако наиболее благоприятный вариант - когда одним агрегатом управляет один микросервис.

Event Storming - метод, представляющий собой практику мозгового штурма для формирования модели предметной области. Метод Event Storming позволяет привлечь к совместному обсуждению представителей бизнеса и технических специалистов. Идея заключается в превращении разработки модели предметной области в совместную деятельность, в результате которой вы получаете общий, объединенный взгляд на задачу.

Основные идеи метода Event Storming:

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

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

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

По сути, DDD ставит бизнес-сферу в центр создаваемого нами приложения. Использование языка бизнеса в нашем коде помогает улучшить знания предметнои области среди разработчиков. Это, в свою очередь, позволяет лучше понимать пользователеи и улучшает коммуникацию между техподдержкои, разработчиками и конечными клиентами. Если вы заинтересованы в переходе к потоковым командам, DDD идеально подоидет в качестве механизма, помогающего согласовать техническую архитектуру с более широкои организационнои структурои. В мире, в котором мы все чаще пытаемся разрушить барьеры между ИТ и «бизнесом», это не так уж плохо.

Примите мои поздравления! Только что мы рассмотрели основные концепции предметно-ориентированного проектирования. Теперь вы обладаете базовыми знаниями по domain-driven design. Для желающих погрузиться глубже, рекомендую обратиться к трудам Эрика Эванса (Eric Evans) и Вона Вернона (Vaughn Vernon). Если материал был полезен, подписывайтесь на мой телеграм-канал. В нем я делюсь своими компетенциями на стыке ИТ и бизнеса. И до скорых встреч, друзья!