Разработка на основе предметной области: Освоение ограниченных контекстов для масштабируемого программного обеспечения

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

Что такое ограниченный контекст?

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

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

Зачем использовать ограниченные контексты?

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

Снижение сложности: Разделив большую предметную область на более мелкие, более управляемые контексты, вы уменьшаете общую сложность системы. Каждый контекст можно легче понять и поддерживать.
Улучшенное сотрудничество: Ограниченные контексты облегчают лучшее общение между разработчиками и экспертами предметной области. Общепринятый язык гарантирует, что все говорят на одном языке в конкретном контексте.
Независимая разработка: Команды могут работать независимо над разными ограниченными контекстами, не наступая друг другу на пятки. Это обеспечивает более быстрые циклы разработки и повышенную гибкость.
Гибкость и масштабируемость: Ограниченные контексты позволяют вам развивать разные части системы независимо друг от друга. Вы можете масштабировать конкретные контексты в зависимости от их индивидуальных потребностей.
Улучшенное качество кода: Ориентация на конкретную область внутри ограниченного контекста приводит к более чистому, более удобному в обслуживании коду.
Соответствие бизнесу: Ограниченные контексты часто соответствуют конкретным бизнес-возможностям или отделам, что упрощает сопоставление программного обеспечения с потребностями бизнеса.

Стратегический DDD: Определение ограниченных контекстов

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

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

Пример: Система электронной коммерции

Рассмотрим большую систему электронной коммерции. Она может содержать несколько ограниченных контекстов, таких как:

Каталог продуктов: Отвечает за управление информацией о продуктах, категориях и атрибутах. Общепринятый язык включает такие термины, как «продукт», «категория», «артикул» и «атрибут».
Управление заказами: Отвечает за обработку заказов, управление отгрузками и обработку возвратов. Общепринятый язык включает такие термины, как «заказ», «отгрузка», «счет» и «оплата».
Управление клиентами: Отвечает за управление учетными записями клиентов, профилями и предпочтениями. Общепринятый язык включает такие термины, как «клиент», «адрес», «программа лояльности» и «контактная информация».
Управление запасами: Отвечает за отслеживание уровней запасов и управление местоположениями складов. Общепринятый язык включает такие термины, как «уровень запасов», «местоположение», «точка повторного заказа» и «поставщик».
Обработка платежей: Отвечает за безопасную обработку платежей и обработку возвратов. Общепринятый язык включает такие термины, как «транзакция», «авторизация», «расчет» и «данные карты».
Движок рекомендаций: Отвечает за предоставление рекомендаций по продуктам клиентам на основе истории их просмотров и поведения при покупках. Общепринятый язык включает такие термины, как «рекомендация», «алгоритм», «профиль пользователя» и «привязанность к продукту».

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

Карты контекста: визуализация взаимосвязей между ограниченными контекстами

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

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

Тактическое DDD: Шаблоны интеграции

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

Вот некоторые распространенные шаблоны интеграции:

Общее ядро: Два или более ограниченных контекста используют общую модель или код. Это рискованный шаблон, поскольку изменения в общем ядре могут повлиять на все контексты, зависящие от него. Используйте этот шаблон экономно и только тогда, когда общая модель стабильна и хорошо определена. Например, несколько сервисов в финансовом учреждении могут совместно использовать основную библиотеку для расчетов в валюте.
Клиент-поставщик: Один ограниченный контекст (Клиент) зависит от другого ограниченного контекста (Поставщик). Клиент активно формирует модель Поставщика для удовлетворения своих потребностей. Этот шаблон полезен, когда один контекст испытывает острую необходимость повлиять на другой. Система управления маркетинговой кампанией (Клиент) может сильно повлиять на разработку платформы данных о клиентах (Поставщик).
Конформист: Один ограниченный контекст (Конформист) просто использует модель другого ограниченного контекста (Upstream). Конформист не оказывает никакого влияния на модель Upstream и должен адаптироваться к ее изменениям. Этот шаблон часто используется при интеграции с устаревшими системами или сторонними сервисами. Небольшое приложение для продаж может просто соответствовать модели данных, предоставленной большой, устоявшейся CRM-системой.
Антикоррупционный слой (ACL): Слой абстракции, который находится между двумя ограниченными контекстами, переводя между их моделями. Этот шаблон защищает нижестоящий контекст от изменений в вышестоящем контексте. Это решающий шаблон при работе с устаревшими системами или сторонними сервисами, которые вы не можете контролировать. Например, при интеграции с устаревшей системой расчета заработной платы ACL может преобразовывать устаревший формат данных в формат, совместимый с системой управления персоналом.
Раздельные пути: Два ограниченных контекста не имеют отношений друг с другом. Они полностью независимы и могут развиваться независимо. Этот шаблон полезен, когда два контекста принципиально разные и не нуждаются во взаимодействии. Внутренняя система отслеживания расходов для сотрудников может быть полностью отделена от общедоступной платформы электронной коммерции.
Сервис открытого хоста (OHS): Один ограниченный контекст публикует хорошо определенный API, который другие контексты могут использовать для доступа к его функциональности. Этот шаблон способствует слабому связыванию и обеспечивает более гибкую интеграцию. API должен быть разработан с учетом потребностей потребителей. Сервис шлюза платежей (OHS) предоставляет стандартизированный API, который различные платформы электронной коммерции могут использовать для обработки платежей.
Опубликованный язык: Сервис открытого хоста использует хорошо определенный и документированный язык (например, XML, JSON) для связи с другими контекстами. Это обеспечивает совместимость и снижает риск неправильной интерпретации. Этот шаблон часто используется в сочетании с шаблоном сервиса открытого хоста. Система управления цепочкой поставок предоставляет данные через REST API с использованием JSON Schema для обеспечения четкого и последовательного обмена данными.

Выбор подходящего шаблона интеграции

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

Распространенные ловушки и антишаблоны

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

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

Ограниченные контексты и микросервисы

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

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

Практические примеры со всего мира

Применение ограниченных контекстов является универсальным, но особенности будут зависеть от отрасли и контекста.

Глобальная логистика: Многонациональная логистическая компания может иметь отдельные ограниченные контексты для *отслеживания отправлений* (обработка обновлений местоположения в реальном времени), *таможенной очистки* (работа с международными правилами и документацией) и *управления складом* (оптимизация хранения и запасов). «Товар», который отслеживается, имеет очень разные представления в каждом контексте.
Международные банковские операции: Глобальный банк может использовать ограниченные контексты для *розничного банкинга* (управление счетами отдельных клиентов), *коммерческого банкинга* (обработка бизнес-кредитов и транзакций) и *инвестиционного банкинга* (работа с ценными бумагами и торговлей). Определение «клиент» и «счет» будет значительно различаться в этих областях, отражая различные правила и потребности бизнеса.
Многоязычное управление контентом: Глобальная новостная организация может иметь отдельные ограниченные контексты для *создания контента* (авторство и редактирование статей), *управления переводами* (обработка локализации для разных языков) и *публикации* (распространение контента по различным каналам). Концепция «статья» имеет разные атрибуты в зависимости от того, создается ли она, переводится или публикуется.

Заключение

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

Действенные идеи

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