Многие коллеги говорят, что мы умело практикуем принципы проблемно-ориентированного проектирования (Domain-Driven Design, DDD). Максимально погружаемся в предметную область, детально анализируем связи и зависимости, уделяем пристальное внимание проектированию систем. Рассказываем, почему это важно для заказчика.
Что такое DDD
Domain-Driven Design — подходы и принципы проектирования, с помощью которых удобно строить системы объектов. На основе абстракций, которые представляют модели предметных областей, можно оптимально масштабировать бизнес-логику системы без изменения фундаментальных частей.
Правильно спроектированная модель позволяет безболезненно расширять бизнес-логику продукта. Для реализации этого требуются усилия со стороны команды и заказчика.
Команда разработки глубоко погружена в проект, обходит подводные камни и учитывает нюансы бизнеса. Тщательное проектирование на старте дает выгоды в дальнейшем сопровождении продукта.
Нет стандартного ответа «Ну что же вы раньше-то не сказали, теперь надо все переделывать». Подходы DDD направлены на гибкое изменение модели и быстрое внедрение изменений.
Погружение в область
Для проектирования по DDD важно детально изучить предметную область. Цель — построить модель ПО, которая отразит бизнес-ценности клиента. Стандартного анализа технического задания и нескольких обсуждений недостаточно. Команда проводит интервью с сотрудниками, определяет приоритеты и строит сценарии.
В этом состоит отличие проектирования по DDD — разработчик глубоко погружается в бизнес, чтобы формализовать его и оптимально смоделировать логику работы.
Что в этом хорошего. Команде важно понимать логические связи, поведение системы и зависимости. Чем полнее картина, тем детальнее будет спроектирована будущая модель. В результате более гибким и расширяемым получится итоговый продукт.
Модель предметной области
После изучения бизнес-логики строится модель предметной области, так называемый домен. На основе него будет реализована программная часть. Домен полностью отражает суть бизнеса, описывается единым языком и ограничивается контекстом предметной области.
Единый язык — принцип, по которому названия в проекте даются в мире заказчика: от переменных до кнопок интерфейса. При поддержке проекта это позволяет всем говорить на одном языке, быстрее считывать код и, как следствие, минимизировать время на вливание в предметную область новых участников проектной группы.
В одном из заказных проектов, связанных с ПО для ЭБУ двигателей, есть рекламная программа для партнеров. Партнер на языке заказчика — участник программы, оплачивающий лицензию для рекламных услуг. В домене такой партнер должен называться Partner, а не Member или Participant. Это начальная ступень для борьбы со сложностью.
Что в этом хорошего. Команда понимает бизнес-ценности ПО, а не слепо следует ТЗ. Программная реализация становится более логичной и готовой к возможным изменениям. Код легко поддерживать специалистам заказчика, новым сотрудникам исполнителя или другим подрядчикам.
Ядро домена и поддомены
На этапе проектирования важно выделять так называемое ядро домена, из которого убрано всё лишнее. В ядре остаются конкурентные преимущества и фундаментальные части бизнес-логики. Всё остальное выносится в субдомены.
С помощью такого деления расставляются приоритеты. Ядро домена — самая важная часть программной реализации. Субдомены можно реализовать позже, передать на аутсорс или адаптировать готовые решения.
Что в этом хорошего. Правильно выбранное ядро домена ложится в основу MVP — минимального жизнеспособного продукта. Такой продукт реализуется в первую итерацию, что ускоряет внедрение и снижает количество доработок и правок.
Выводы
Проектирование по DDD способствует глубокому взаимопониманию между исполнителем и заказчиком. На первое место ставятся бизнес-цели компании. В результате продукт точно отражает работу и конкурентные преимущества организации.
За счет продуманной модели снижается стоимость поддержки. Это важно для заказчиков: бизнес-процессы часто меняются и появляются новые.
С технической стороны проектирование по DDD позволяет не привязываться к инфраструктуре. Без изменения бизнес-логики можно переехать на другие технологии: от баз данных до frontend.