☕ Пример проекта Java Backend: DDD, микросервисы, Spring Cloud и AWS (Часть 3)
Domain Driven Design дает большие возможности по созданию крупных проектов, которые в будущем становятся надежными и легко масштабируемыми. Как пройти полный проектный цикл, от бизнес-модели до AWS? Обсудить Первая и вторая части серии были посвящены подготовительному этапу. На примере минималистического проекта Spring Boot мы проверили полный цикл работ и выставили приложение на AWS. В этой статье мы начинаем второй этап, архитектурный. Нам придётся пробежаться по теории предметно-ориентированного проектирования (Domain-Driven Design или DDD). Надо будет разобраться с предметной областью, ограниченными контекстами, моделями и сервисами предметной области. Также проведём проектирование, в нашем случае это будет экстренная медицинская помощь, где мы применим DDD при моделировании архитектуры. DDD – это набор правил, которые позволяют принимать правильные проектные решения. Такой подход позволяет значительно ускорить процесс разработки программного обеспечения в незнакомой области, а также с легкостью развивать и сопровождать его в будущем. DDD – это борьба со сложностью бизнес-логики. DDD состоит из… – архитектурной части (стратегическое моделирование): – реализационной части (тактическое моделирование): Примечание Рекомендации по последовательности действий при проектировании. Начните со стратегического моделирования: Затем, переходите к тактическому моделированию: Давайте проясним основные понятия архитектурной и реализационной частей. Представьте, вы начали новый проект (это может быть сфера медицины, страхования или финансов) и вам необходимо собрать как можно больше информации по предметной области. Вы начинаете ее изучать и исходя из требований проекта исследуете определённую область знаний. Общение со специалистами со стороны заказчика – это необходимость в проектной разработке. В любом случае, в процессе реализации проекта, вы будете вынуждены пополнять свои знания исходя из задач предметной области. В процессе работы вы должны договориться с заказчиком на каком языке вы будете общаться, вам придется создавать единый словарь терминов и определений, которые понадобятся при проектировании архитектуры и реализации проекта. В жизненном цикле проекта словарный запас этого языка будет постоянно пополняться и расширяться из знаний предметной области. Определение предметной области является начальным этапом предметно-ориентированного проектирования – это главная бизнес-задача. В зависимости от сложности проекта, предметных областей может быть от одной и более. Начиная проектировать, вы предполагаете разделить основную бизнес-задачу на подзадачи/функции, то есть создаете поддомены в предметной области. Их также можно назвать ограниченными контекстами. Определенные логикой, они имеют четкие границы и взаимодействуют с другими ограниченными контекстами через установленные интерфейсы и контракты. В процессе создания решения определяется модель предметной области, она и является самой важной частью бизнес-логики ограниченного контекста. На языке бизнеса определяются следующие понятия (в сопоставлении с DDD определениями): Соотнесение бизнес-языка и технического языка Далее, в процессе создания модели предметной области примерного проекта эти понятия будут раскрыты и реализованы. *** Проект: «Экстренная медицинская помощь» Первичная регистрация пациента: Рабочий процесс: Конечно, со стороны заказчика может быть предложен расширенный вариант UX. В нашем вымышленном проекте достаточно и этой информации. Определяем основную предметную область – это дистанционная экстренная медицинская помощь пациенту. Определяем артефакты основной предметной области – у нас будут следующие артефакты: Мы должны определить четкое разделение основной предметной области на различные бизнес-области, независимые и со своим бизнес-языком. Разделяем основную предметную область на поддомены Определяем несколько ограниченных контекстов. В нашем случае, контексты, это: вызов (recourse) Эта область включает обращение пациента в службу экстренной помощи, а также следующие операции: диагностика (diagnosis) Эта область определяет состояние здоровья пациента и выявляет степень экстренности оказания медицинской помощи, а также следующие операции: лечение (treatment) Эта область включает в себя процесс лечения пациента, а также следующие операции: отслеживание (tracking) Эта область включает в себя процесс оказания экстренной помощи пациенту, а также следующие операции: Примечание Рекомендации при реализации ограниченных контекстов Давайте установим правила проектирования для нашего приложения. в отношении ограниченных контекстов: для связи микросервисов: В проекте мы имеем четыре основные бизнес-области и предполагаем сопоставлять одну бизнес-область к одному ограниченному контексту. У нас будет два основных набора артефактов для модели предметной области. – для модели основной предметной области: – для операций модели предметной области: Агрегаты (Aggregates) в ограниченном контексте Агрегат – это единый элемент во время любых операций, которые обновляют состояние данного агрегата. Агрегаты отвечают за сохранение всех состояний и бизнес-правил, а также устанавливают область видимости ограниченного контекста. Каждый агрегат определяет область логической целостности ограниченного контекста и содержит в себе: Идентификаторы агрегатов Каждый агрегат должен быть обозначен идентификатором агрегата (Aggregate Identifier) и реализуется при помощи бизнес-ключа (Business Key). Сущности (Entities) Каждая сущность в ограниченном контексте должна иметь свою идентичность, они привязаны к агрегату и не могут существовать без агрегатов. Определяем сущности в наших агрегатах. Объекты-значения (Value-Objects) Они не имеют собственной идентичности и их можно заменить в любом экземпляре агрегата. Команды (Commands) Это операции, которые требуют изменения состояния в ограниченном контексте. Запросы (Queries) Это операции, которые запрашивают состояние ограниченного контекста. События (Events) сообщают об изменении состояния ограниченного контекста. Команды, запросы, события Саги (Sagas) В распределенных системах на основе микросервисов реализуется механизм поддержания логической целостности данных при взаимодействии нескольких микросервисов. Саги реализуют это методом хореографии (Event Choreography) или оркестровки событий (Event Orchestration). Сага позволяет приложению поддерживать согласованность данных между сервисами без использования распределенных транзакций. Введем следующие определения. Ограниченный контекст: Существует три типа сервисов модели предметной области для ограниченного контекста: Сервисы предметной области Дополнительные материалы • Блеск и нищета модели предметной области • Реализация ограниченного контекста • Паттерн: Сага • Мы вкратце прошлись по DDD применительно к вымышленному проекту экстренной медицинской помощи. Были даны определения для ограниченных контекстов, агрегатов, модели предметной области и других понятий, необходимых при предметно-ориентированном проектировании. А как же связать DDD с микросервисами? В следующей статье мы начнем третий этап – технический. На примере кодов попробуем применить предметно-ориентированное проектирование с микросервисами.Предметно-ориентированное проектирование
Основные определения
В чем преимущество DDD?
Архитектурная часть
Знание предметной области (Domain Knowledge)
Единый язык (The Ubiquitous Language)
Предметная область (Problem Space)
Поддомены (SubDomain), ограниченные контексты (Bounded Context)
Реализационная часть
Модель предметной области (Domain Model)
Пользовательские истории (User Experience, UX)
Основные определения
Сценарий действий, как это будет происходить
Строим архитектуру проекта
Поддомены (ограниченные контексты)
Бизнес-область Ограниченный контекст вызов (recourse) Вызов (recourse) диагностика (diagnostics) Диагноз (diagnose) лечение (treatment) Лечение (treatment) отслеживание (tracking) Отслеживание (tracking) Определим модель предметной области
Давайте, разберемся со всеми по порядку
Определяем сервисы модели предметной области
Резюме
- 1 views
- 0 Comment
Свежие комментарии