Современные проекты требуют не только высокотехнологичных решений, но и четкого понимания бизнес-процессов для всех его участников. Илья Сергунин поможет разобраться в тонкостях DDD и расскажет, почему он выгоден для вашего бизнеса.
Предметно-ориентированное программирование (англ. — Domain-Driven Design или DDD) — это методология разработки программного обеспечения, которая формирует единый язык для разработчиков и других участников процесса и использует для построения архитектуры концепцию реального мира. Главная цель DDD — упрощение процесса разработки.
Основные принципы, на которых строится подход предметно-ориентированного программирования:
● Единый язык — разработчики, менеджеры, аналитики и другие участники процесса вырабатывают на встречах список ключевых терминов и придерживаются их во всех процессах. Например, у нас в «Авито» мы договорились, что запись в базе данных будет называться объявлением, пользователь — продавцом или покупателем, вместо CRUD-операций используем конкретные бизнес-сценарии. В бизнесе часто бывает такое, что менеджер и разработчик, упоминая разные термины, говорят об одних и тех же вещах и не понимают друг друга. Единый язык помогает этого избежать.
● Ограниченные контексты — это небольшая область внутри бизнеса вокруг бизнес-процесса, где используется отдельный единый язык, свой для каждого ограниченного контекста. Например, ограниченный контекст «Доставка» содержит сущности «Товар» и «Пользователь», при этом последняя подразделяется на «Продавца» и «Покупателя». Переводя на бизнес-язык, можно сказать, что бизнес-процесс «Доставка» заключается в том, что Продавец отправляет Товар Покупателю. При этом, в рамках этого ограниченного контекста могут происходить различные дополнительные процессы — например, Покупатель может отказаться от Товара, получить его или отправить обратно Продавцу.
Ограниченные контексты формируют карту контекстов — то есть, сами контексты + взаимосвязи между ними.
Чтобы лучше понять DDD, давайте также разберемся в основных терминах:
Домен (domain) — это наша основная бизнес-область. В моем случае это «Авито» — доска-агрегатор объявлений. Чтобы работать в подходе DDD, мы проводим собрание, где определяем ключевые бизнес-процессы и разбиваем домен на поддомены.
Поддомены (subdomains) — это области, которые отражают основной функционал домена. В идеальном случае поддомены соответствуют ограниченным контекстам. При этом основная область называется смысловым ядром (core domain). То есть, именно над этой функциональностью работают лучшие специалисты компании, именно сюда в первую очередь вливается бюджет, и именно это определяет бизнес-ценность продукта. Также выделяются:
● служебные поддомены (supporting subdomain) — области, которые помогают ядру функционировать;
● неспециализированные поддомены (generic subdomain) — вспомогательные, но не критичные для функционирования ядра области, их можно заменить другими или отказаться от них.
Пространство задач — это смысловое ядро (core domain) + те поддомены, которые оно использует. Это пространство показывает стратегические задачи, которые решаются для выполнения главных бизнес-целей. Определение пространства задач влияет на выделения пространства решений.
Пространство решений — это конкретные ограниченные контексты, которые способствуют решению этих стратегических задач. То есть, это те IT-решения, которые помогают достичь бизнес-цели.
Как DDD используется на практике
Подход успешно реализуется в различных сферах бизнеса благодаря тому, что позволяет делать сложные процессы проще. Поэтому наиболее популярные области, в которых он применяется, связаны со сложными многоуровневыми IT-архитектурами. Приведу несколько примеров.
Финансовая отрасль | Банковская система
● Доменная область: онлайн банкинг
● Ограниченные контексты: интернет-банкинг, обработка платежей и управление счетами, клиенты (физические и юридические лица)
● Ядро — обработка платежей, самая важная часть, где сосредоточена основная прибыль и риски бизнеса.
Здравоохранение | Информационная система для управления медицинскими записями
● Доменная область: медицинская система в поликлинике или больнице
● Ограниченные контексты: пользователи (пациенты, врачи), медицинские карты, процессы обслуживания, ОМС, ДМС
● Ядро — правила управления записями и взаимодействия между...