Продолжая взаимодействие с настоящим сайтом, вы выражаете свое согласие с тем, что ваши пользовательские данные (сведения о местоположении; тип и версия ОС; тип и версия Браузера; тип устройства и разрешение его экрана; источник откуда пришел на сайт пользователь; с какого сайта или по какой рекламе; язык ОС и Браузера; какие страницы открывает и на какие кнопки нажимает пользователь) будут обрабатываться ООО «Тадос» в целях сбора статистических данных о посетителях сайта и функционировании сайта в течение 3 месяцев. В случае, если вы не хотите, чтобы ваши данные обрабатывались, покиньте сайт.

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

Что такое DDD

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

При масштабном изменении бизнес-логики не приходится переписывать всё с нуля

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

Снижаются затраты на расширение функционала ПО

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

Новая бизнес-логика не конфликтует с текущей реализацией

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

Погружение в область

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

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

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

Модель предметной области

После изучения бизнес-логики строится модель предметной области, так называемый домен. На основе него будет реализована программная часть. Домен полностью отражает суть бизнеса, описывается единым языком и ограничивается контекстом предметной области.

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

В одном из заказных проектов, связанных с ПО для ЭБУ двигателей, есть рекламная программа для партнеров. Партнер на языке заказчика — участник программы, оплачивающий лицензию для рекламных услуг. В домене такой партнер должен называться Partner, а не Member или Participant. Это начальная ступень для борьбы со сложностью.

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

Ядро домена и поддомены

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

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

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

Выводы

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

За счет продуманной модели снижается стоимость поддержки. Это важно для заказчиков: бизнес-процессы часто меняются и появляются новые.

С технической стороны проектирование по DDD позволяет не привязываться к инфраструктуре. Без изменения бизнес-логики можно переехать на другие технологии: от баз данных до frontend.

Работа по Domain-Driven Design
Средняя оценка 5 Проголосовало 2