DDD, или Бизнес превыше всего: проектируем ПО в текущих условиях

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

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

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

Одним из наиболее эффективных и совершенных подходов в проектировании ПО в этом отношении является «Domain-Driven Design». Впервые его описал Эрик Эванс в 2004 году. И несмотря на то что подходу уже 20 лет, он остается актуальным, хотя и не во всех случаях оправдан. В этой статье расскажем, чем этот подход может быть полезен бизнесу и где применим, а также поделимся советами на основе многолетней практики SimbirSoft по внедрению подхода.
 

Domain-Driven Design: что это такое и кому подходит

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

Прежде чем рассмотреть преимущества такого подхода при разработке, остановимся на инструментах, за счет которых он реализуется — Ubiquitous Language (универсальный язык описания) и Bounded Context (ограниченный контекст).

Ubiquitous Language — универсальный язык описания. Он сводит к минимуму барьеры, неточности и несоответствия, возникающие в процессе коммуникации между аналитиками  и разработчиками. Специалисты совместно вырабатывают общую терминологию, названия процессов и наборы характеристик, которые будут использоваться в ходе работы. За счет этого команда разработки глубже погружается в предметную область заказчика и с большей гибкостью, соответствием реальным бизнес-процессам может реализовать проект.

Bounded Context — ограниченный контекст. Это граница, способ разделения всей предметной области заказчика на отдельные домены. Приобретает особую значимость при разработке крупных и разветвленных систем, бизнес-процессы которых часто могут иметь сложные взаимосвязи. За счет использования ограниченного контекста подкоманды разработки могут фокусироваться на конкретных модулях системы, не тратя время на изучение остальных, и брать во внимание только необходимые для реализации точки интеграции с ними. При необходимости ограниченные контексты могут иметь собственные универсальные языки описания, что также придает дополнительную гибкость всему процессу реализации.

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

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

Преимущества и сложности использования DDD

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

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

Основные преимущества:

• Сокращение затрат на сопровождение и дальнейшее развитие программного продукта. При строгом соблюдении подхода со временем на поддержку legacy-кода будет уходить меньше времени и средств, чем при использовании других подходов.
• Более точные и эффективные решения. Использование разработчиками и аналитиками общего универсального языка описания значительно сокращает время принятия решений при устранении недостатков или добавлении новых функций, а значит повышает качество реализации приложения и степень соответствия ожиданиям клиентов и рынка.
• Разработчики становятся экспертами. Фокус подкоманд или отдельных специалистов на конкретных доменах или их частях, определенных с помощью ограниченного контекста, дает им возможность за короткий промежуток времени стать экспертами в конкретной области (своей зоне ответственности). Это также положительно сказывается на скорости и точности принятия решений.
• Технологическая гибкость. Когда ключевым в процессе разработки становится отображение реальных бизнес-процессов и их составляющих, выбор отдельных технологий реализации, как правило, отходит на второй план. Это дает широкую гибкость. При грамотном построении архитектуры приложения с использованием принципов DDD добавление или замена технологий будет происходить с минимальными затратами, поскольку компоненты системы имеют высокий уровень независимости друг от друга. Шанс повлиять на другие части приложения при доработках будет минимальным. К примеру, миграция с одной СУБД на другую не потребует изменений бизнес-логики и будет ограничена лишь в слое непосредственной интеграции с хранилищем данных. 

Несмотря на весомые преимущества, использование DDD влечет и ряд сложностей:

• Большая вовлеченность заказчика в разработку. Чтобы DDD работал с максимальным результатом, необходима вовлеченность в процесс специалистов, хорошо знакомых с предметной областью. Особенно это важно на первых этапах при выработке вышеупомянутых универсальных языков описания и ограниченных контекстов. Это требует от команды аналитики или, при ее отсутствии, от непосредственных заказчиков больше внимания и времени, чем при использовании отличных от DDD подходов. Если есть возможность, советуем на постоянной основе включить в команду проект бизнес-аналитиков, которые хорошо понимают автоматизируемые процессы.
• Необходимость перестройки процессов разработки. Несмотря на то что DDD появился относительно давно, не все разработчики знакомы с этим подходом, а специалистов, которые применяли его на практике, — еще меньше. Да и не каждый язык программирования подойдет под DDD. У команды, не работавшей с подходом ранее, только на изучение литературы и выработку соглашения уйдет несколько месяцев. Поэтому внедрение DDD потребует времени на погружение команды в новые принципы работы и оттачивание их использования, а потом не нарушать их при дальнейших доработках.
• Отсутствие «правильного рецепта». У DDD есть только общие рекомендации, поэтому на практике командам бывает сложно договориться о том, как правильно. Даже у таких компаний, как Додо Пицца, Сбер и других, реализация отличается между собой. Результативность и скорость разработки будет сильно зависеть от наличия опытного архитектора, который должен глубоко погрузиться в бизнес-задачу и спроектировать систему. Решить эту и предыдущую проблему поможет привлечение внешних специалистов с соответствующим опытом. 
• Сложности при смене архитектуры. Эта проблема актуальна, когда продукт уже находится в стадии активной разработки или появилась необходимость его доработать. Сложность предметной области продукта, составных частей и взаимосвязей между ними может быть настолько высока, что процесс смены архитектуры потребует больших временных ресурсов и высокой квалификации исполнителей. Здесь надо четко понимать, как смена архитектуры позволит решить конкретные задачи и стоит ли потенциальный экономический эффект потраченных средств. Но это актуально не только для DDD. На практике любая перестройка архитектуры приложения в процессе разработки требует глубокого и взвешенного анализа.

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

Переход на DDD: с чего начать 

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

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

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

Это те базовые шаги, которые необходимы для того чтобы начать внедрять DDD в ваш проект.

Как упростить процесс внедрения DDD: подключаем Event Storming

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

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

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

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

Event-storming подразумевает под собой множество различных практик и правил. Остановимся на основных разновидностях этого инструмента:

• Крупномасштабное исследование. На этом этапе происходит аккумулирование всей информации о предметной области крупными блоками. Основную роль здесь играют специалисты от бизнеса, ориентирующиеся в процессах.
• Моделирование процесса. На этом этапе происходит детализация информации, полученной на предыдущем этапе. Вся бизнес-логика делится на отдельные процессы, внутри которых специалисты выявляют недочеты, противоречия и совместно ищут пути их решения. Здесь команда бизнеса и разработки активно взаимодействуют.
• Проектирование. На этом этапе полученные ранее знания, которые после их детализации и согласования сформировали отдельные процессы, ложатся в основу принятия архитектурных решений. Здесь основную роль играет команда разработки и/или архитектор. Этот этап формирует подходы к реализации системы и вплотную подводит к началу ее непосредственной реализации.

Event-storming при правильном использовании помогает выстроить эффективное взаимодействие между командой разработки и бизнесом. Это позволяет им «говорить на одном языке», что ведет к получению значительной части преимуществ от внедрения DDD, которые были описаны выше.

Вместо вывода

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

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

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