Преимущества Domain-Driven Design для бизнеса

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

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

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

Что такое Domain-Driven Design

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

Принципы DDD были сформулированы Эриком Эвансом в книге “Domain-Driven Design: Tackling Complexity in the Heart of Software”, опубликованной в 2004 году. Но и сейчас они продолжают набирать популярность во всем мире разработки, в том числе на проектах нашей компании. 

Прежде всего, в DDD коренным образом пересматривается процесс взаимодействия разработчиков с экспертами предметной области. До начала работы над проектом все вовлеченные стороны формируют единый язык (ubiquitous language). Он, в зависимости от специфики бизнеса и предпочтений команды, может быть представлен в формате глоссария терминов, в виде диаграмм, понятных всем участникам проекта, или развернутой документации. В результате все участники: разработчики, аналитики, эксперты предметной области, менеджеры  — называют вещи теми именами, о которых договорились, то есть решается проблема «сломанного телефона» и не тратится время на переделывание неверно понятых задач.

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

В качестве простого примера рассмотрим расчет индексов потребительской лояльности для последовательности периодов времени, для каждого из которых известны количества нажатий на кнопки “нравится”, “нейтрально” и “не нравится”.

Часть кода на PHP, делающая это вычисление, может выглядеть так:

Используя оговоренные термины, сделаем код более читаемым, понятным:

foreach ($pointsList as $point) {

   if ($point->npsAvailable()) {

       if ($point->overallSum() > 0) {

           $nps = $point->promotersPerCent() - $point->detractorsPerCent();

           $point->setNPS($nps);

       } else {

           $point->setNPS(null);

       }

   }

}

Разумеется, в этом примере придется дописать еще немного кода для реализации методов npsAvailable, overallSum, promotersPerCent и detractorsPerCent, но зато мы получаем легко читаемый код.

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

Эрик Эванс

Фото training.dddeurope.com

Подход DDD подразумевает, что каждому участнику проекта доступна полная и целостная информация о предметной области и бизнес-процессах. На начальном этапе при взаимодействии всех участвующих в проекте сторон разрабатывается модель предметной области. Так как невозможно составить всеобъемлющую модель любого более или менее сложного бизнеса, обычно выделяют предметные подобласти (subdomains), среди которых выделяют смысловое ядро (core domain)  — наиболее важную, первостепенную для бизнеса предметную подобласть, то, что делает организацию конкурентоспособной.

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

На проектах, живущих более нескольких лет, нередко возникает необходимость смены технологий. Например, за время существования проекта могут появиться новые фреймворк или СУБД, более подходящие под современные требования к разработке, или просто могут перестать поддерживаться старые. Либо может потребоваться замена всей технико-технологической базы, чтобы выдерживать возросшую нагрузку в ситуации недооцененного роста аудитории, объемов данных, требований к быстродействию. Бизнес-процессы тоже со временем меняются, поэтому могут меняться и требования к системе  — добавление каких-либо новых функций, которые невозможно или нецелесообразно реализовывать на технологиях, изначально используемых в проекте. Почти каждый разработчик может вспомнить (недобрым словом) такие проекты, где в какой-то момент назрела объективная необходимость смены технологии и пришлось переписывать заново почти всю логику, так как она была сильно завязана на имеющиеся технологии.

Использование DDD-подхода и в этом случае избавляет разработчиков от мук и лишней работы, а также экономит время и бюджет заказчику, так как с самого начала на проекте используется так называемая «луковая» архитектура, фундаментальное правило которой состоит в том, что любой модуль приложения может зависеть от более близких к центру «луковицы» модулей, но не может зависеть от более дальних. Вся основная бизнес-логика (доменная модель) находится в центре, то есть в том слое, который не зависит ни от каких внешних слоев и при изменении инфраструктуры не требует доработок. Поэтому в рассматриваемом случае изменения коснутся только «внешних» слоев: сервисного слоя (application services) и собственно слоя инфраструктуры.

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

Особенности использования

Мы используем предметно-ориентированный подход не для каждого нового проекта. Почему?

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

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

Но даже там, где по каким-либо причинам нет возможности в полном объеме применить DDD, все же можно и целесообразно использовать отдельные принципы предметно-ориентированного дизайна.

Фото: pixabay.com

Итог

Итак, Domain-Driven Design  — не панацея, но очень мощный и эффективный подход к разработке проектов со сложной бизнес-логикой. DDD требует от всех участвующих сторон высокой степени вовлеченности в проект, готовности и способности достаточно глубоко изучить предметную область и найти общий язык. При грамотном применении подхода приложенные усилия оправдываются и дают значительные преимущества для бизнеса:

• архитектуру приложения, максимально точно отражающую бизнес и учитывающую все его особенности;

• использование единого языка для коммуникации всех участников проекта сводит на нет затраты времени на переделывание неправильно понятых задач и исправления ошибок в архитектуре;

• код становится легко читаемым и понятным для экспертов в предметной области, что позволяет им контролировать правильность реализуемой логики и предотвращать ошибки на начальных этапах разработки;

• независимость бизнес-логики (доменной модели) от инфраструктуры, что позволяет при необходимости с минимальными затратами менять используемые технологии и масштабировать проект.

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