CC BY
22
МЕТОДИЧЕСКИЕ МАТЕРИАЛЫ ПО ФОРМИРОВАНИЮ КАРТЫ КОНТЕКСТОВ Р. Дандан, магистрант
Московский государственный технический университет им. Н.Э. Баумана (Россия, г. Москва)
001:10.24412/2500-1000-2022-5-2-21-25
Аннотация. В ходе исследования были определены и обсуждены основные концепции предметно-ориентированного проектирования, а также объяснены тактические и стратегические шаблоны. В соответствии с этими шаблонами была проанализирована система электронной коммерции, и в качестве логических границ изучаемой области были определены ограниченные контексты. Также была разработана контекстная карта, которая представляет собой интеграцию между различными ограниченными контекстами.
Ключевые слова: предметно-ориентированное проектирование, ограниченный контекст, карта контекстов, тактические шаблоны БББ, стратегические шаблоны БББ, система электронной коммерции.
В своей книге Эрик Эванс сформулировал предметно-ориентированное проектирование (DDD) как язык шаблонов. Это набор связанных шаблонов проектирования, предназначенный для поддержки разработки программного обеспечения, особенно в сложных областях.
Он состоит из коллективной мудрости из индустрии программного обеспечения, набора шаблонов, принципов и практик, которые позволят командам сосредоточиться на том, что является ключевым для успеха бизнеса, при разработке программного обеспечения, которое управляет сложностью как в технической, так и в бизнес-сферах.
Тактический шаблон DDD определяет модели предметной области с большей точностью. Тактические шаблоны применяются в едином ограниченном контексте [1].
Стратегические шаблоны сосредоточены на интеграции ограниченных контекстов, которые являются логическими границами в системе. Ограниченные контексты определяют общий язык или модель внутри поддомена. Обычно, когда язык или модель начинают менять свое значение, это означает, что может быть создан другой ограниченный контекст.
Чтобы визуализировать, как взаимодействуют различные ограниченные контексты, DDD имеет универсальную технику, называемую картой контекстов. При создании карты контекстов можно определить потенциальные логические границы в системе. Стратегические шаблоны работают за счет конкретной интеграции этих различных ограниченных контекстов.
В данной статье изучается система электронной коммерции, использующая тактические и стратегические шаблоны Предметно-ориентированного проектирования. Обсуждается, как реализовать эти шаблоны для разработки контекстной карты данной системы, которая определяет связь между различными ограниченными контекстами.
Общее описание анализируемого примера системы
Электронная коммерция, или (Е-соттегсе), относится к покупке и продаже товаров и услуг через Интернет. По сути, электронная коммерция - это люди, процессы и технологии, позволяющие потребителю или бизнесу приобретать товары или услуги у другого бизнеса или отдельного лица.
В статье взят пример домена электронной коммерции для применения тактического и стратегического шаблона DDD для
определения ограниченных контекстов, универсального языка и карты контекстов.
Компания электронной коммерции может потребоваться следующее:
- каталог товаров (Product catalog);
- заказ (Order);
- платежный поток (Payment flow);
- транспортная логистика (Shipping logistics);
- счет (Invoice);
- инвентарь (Inventory);
- управление идентификацией (Identity managment).
Применение тактических шаблонов DDD
Начало будет с тактическими шаблонами:
Сущность - это объект с уникальной идентичностью, которая сохраняется во времени. Каждая сущность уникально идентифицируется идентификатором, а не атрибутом [1]; В данном примере электронной коммерции «Заказ», «Продукт» и «Пользователь» являются сущностями.
Объект значения. неизменяемый объект, представляющий (составное) значение, имеющее значение предметной области [1]. В данном примере электронной коммерции «Orderltem», «Цена продукта» и «Профиль пользователя» являются объектами значений.
Агрегат - это набор из одной или нескольких связанных сущностей (и, возможно, объектов-значений). Каждый агрегат имеет одну корневую сущность, называемую агрегатным корнем. Совокупный корень отвечает за контроль доступа ко всем членам его совокупности. он также отвечает за обеспечение согласованности агрегата [1].
В данном примере электронной коммерции есть «Заказ», который имеет несколько элементов «Orderltem», каждый из которых относится к определенному количеству приобретаемых продуктов. Добавление и удаление элементов в «Заказ» должно контролироваться «Заказом» - части приложения не должны иметь возможность обращаться и создавать отдельный элемент «OrderItem» как часть «Заказа» без прохождения «Заказа». При удалении
«Заказа» должны быть удалены все связанные с ним элементы «Orderltem». Итак, «Заказа» имеет смысл как корень агрегата.
События домена. События домена можно использовать для уведомления других частей системы, когда что-то происходит. Как следует из названия, события домена должны означать что-то внутри домена [1]. Например, «Доставка была отменена» (Canceled Delivery) - это событие домена. В данном примере электронной коммерции есть такие события домена, как «ProductCreated», «ProductUpdated» в отношении «Каталог товаров» и «OrderPlaced», «OrderPaid» в отношении «Заказа», а также «UserRegisterd» в отношении «Управления идентификацией».
Ограниченный контекст
При определении ограниченного контекста нет стандартного ответа. Это зависит исключительно от текущих потребностей и может быть скорректировано, даже если команда более знакома со знанием предметной области.
Ограниченный контекст может быть не только границей между языком и программой, но и границей между командами. Следовательно, взаимосвязь между ограниченным контекстом часто связана с тем, как разные команды видят отношения сотрудничества друг друга.
Итак, ограниченный контекст - это лингвистическая граница. «Заказчик» действует по-другому, это признак того, что существуют разные ограниченные контексты.
Понятие «Заказчика» имеет разное поведение, обязанности и даже разные имена в разных ограниченных контекстах, а именно:
- в ограниченном контексте «Управления идентификацией» он действует как «Участник», и его релевантная информация - это имя, личная информация, уровень членства, бонусные баллы за членство;
- в ограниченном контексте «Каталога товаров» он действует как «Зритель», и его релевантная информация - это история предыдущих покупок, лояльность, доступные продукты, скидки;
- в ограниченном контексте «Покупки» он действует как «Покупатель», и его релевантная информация - это имя, запись заказа;
- в ограниченном контексте «Транспортной логистики» он действует как «Получатель», и его важная информация -это имя, контактная информация, адрес и другие термины;
Применительно к упомянутой выше электронной коммерции нижеследующее
Размышляя об ограниченном контексте, разработчиков просят отказаться от исследования технических деталей и расставить приоритеты для бизнес-возможностей. Ограниченный контекст обеспечивает отличную границу для системы.
Карта контекстов
По мере развития модели возникнет необходимость в создании взаимо-связи между ограниченными контекстами, и для этой цели используется карта контекстов.
Карта контекстов - это диаграмма, которая дает полное представление о разрабатываемой системе. На схеме каждый элемент представляет ограниченный контекст.
Связи между элементами карты контекстов отображают отношения, существующие между ограниченными контекстами.
разделено на три ограниченных контекста, а именно: «Каталог товаров» (Catalog), «Purchase» (покупка) и «Identity» (управление идентификацией). Объект домена каждого режима проектирования (сущность, объект значения, агрегирование, событие домена) в тактическом дизайне будет выглядеть в ограниченном контексте, как показано на рисунке 1.
DDD определяет несколько реляционных шаблонов.
Реляционные шаблоны идентифицируют вышестоящую команду и нижележащую команду. Вышестоящая команда (обозначается буквой и) - это команда, которая влияет на нижележащую команду и может привести к ее изменению. Обозначается буквой Б, нижележащая команда пассивной и претерпевает изменения в вышестоящей команде.
Карта контекстов является частью стратегического шаблона. Он не создает код или развертываемые артефакты, но может быть чрезвычайно полезен для лучшего понимания системы.
Несколько ключевых случаев в контексте исследований электронной коммерции: - уровень членства должен определяться при оформлении корзины покупок. Ес-
Рис. 1. Ограниченный контекст системы электронной коммерции
ли это VIP, будет соответствующая скидка;
- при просмотре продуктов некоторые продукты могут видеть только клиенты определенного уровня. Например, большое количество пачек сигарет могут посмотреть только представители элиты;
- при оформлении покупки в корзине, необходимо получить информацию о продукте из каталога продуктов, чтобы рассчитать цену;
Краткое объяснение отношений между ограниченными контекстами на предыдущей карте контекстов:
Общее ядро (Shared kernel) Контекст покупок и контекст анализа доходов должны иметь модель заказа, а повторение модели «Заказа» в двух местах не приносит большой пользы, поэтому можно рассмотреть общее ядро.
Предохранительный уровень
(Anticorruption layer) ACL
Наиболее распространенный сценарий -интеграция сторонней системы или устаревшей системы. Замена устаревшей системы - это путь, полный трудностей, и устаревшая система обычно является наиболее прибыльной частью системы. Вместо этого можно добавить ACL в
- при совершении покупок требуется сторонний платеж для обработки денежного потока;
- необходимо интегрировать стороннюю логистику, чтобы клиенты знали о ходе логистики;
- система анализа доходов должна обмениваться данными с системой покупок.
На рисунке 2 показана карта контекстов системы электронной коммерции.
ограниченный контекст при использовании устаревшей системы, чтобы он не влиял на разработку.
Служба с открытым протоколом (Open host service) OHS/ Общедоступный язык (Published language) PL
Вышестоящая команда определяет протокол, позволяющий нижележащей команде использовать службу в соответствии с соглашением, и делает соглашение общедоступным, чтобы его могли использовать те, кто хочет его использовать [2].
Это часто происходит, когда вышестоящую команду необходимо интегрировать с несколькими нижестоящими командами. Если каждая нижележащая команда имеет специальный уровень преобразования,
Рис. 2. Карта контекстов системы электронной коммерции
стоимость которого слишком высока, лучше написать вышестоящую службу с открытым протоколом OHS, чтобы уменьшить количество нижележащих пользователей.
Кроме того, он в основном используется с опубликованным языком. Open Host Service определяет протокол, а опубликованный язык - это языковой формат протокола для передачи данных, например XML, JSON и т. Д.
Кроме того, он в основном используется с общедоступным языком. OHS определяет протокол, а общедоступный язык -это язык формат протокола для передачи данных, например XML, JSON и т. д.
Конформист (Conformist)
Используемая стоимость внешних систем слишком высока. Это характерно для двух отделов крупных компаний, которые сотрудничают между собой крупными предприятиями.
Хотя конформисты считают подчиненных очень беспомощными, раннее распо-
Библиографический список
1. Microsoft. Using tactical DDD to design microservices. - [Электронный ресурс]. - Режим доступа: https://docs.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd
2. O'Reilly. Chapter 4. Context mapping. - [Электронный ресурс]. - Режим доступа: https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/ch04.html
знавание конформистских отношений между командами позволяет подчиненным распределять ресурсы и становиться самостоятельными.
Заказчик-поставщик (Customer-supplier)
Когда ограниченный контекст группы имеет вышестоящую и нижележащую связь (односторонняя зависимость), вышестоящая сторона может проходить независимо от нижележащей стороны, исходящая нижележащая сторона будет ограничена областью разработки вышестоящей стороны [2].
Заключение. В работе были проведены исследования тактических и стратегических шаблонов предметно-ориентированного проектирования. Пример системы электронной коммерции был проанализирован в соответствии с упоминаемыми шаблонами, а также предоставлены ограниченные контексты и карты контекстов, объяснены и разработаны.
METHODOLOGICAL MATERIALS ON THE FORMATION OF CONTEXT MAP
R. Dandan, Graduate Student
Bauman Moscow State Technical University
(Russia, Moscow)
Abstract. In the course of the study, main concepts of domain driven design were defined and discussed, tactical and strategic patterns with were explained. An e-commerce system was analyzed according to these patterns, and bounded contexts were identified das logical boundaries of the studied domain. A context map, which represents the integration between different bounded context, was also developed.
Keywords: domain driven design, bounded context, context map, tactical patterns DDD, strategic patterns DDD, E-commerce system.
