DDD (Receive Driven Design) серия общих шаблонов архитектуры DDD

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

Ниже приведены общие шаблоны архитектуры DDD:

• Многоуровневая архитектура DDD

• Аккуратная архитектура

• Шестиугольная архитектура

• Многоуровневая архитектура DDD против аккуратной архитектуры против гексагональной архитектуры

• Архитектура, управляемая событиями

• CQRS ( Сегрегация ответственности за запрос команд )架构

• Шаблон проектирования событий домена в микросервисах

• Шаблон проектирования событий домена между микросервисами

Многоуровневая архитектура DDD

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

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

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

О преимуществах многоуровневой архитектуры Мартин Фаулер дал ответ в книге «Паттерны архитектуры корпоративных приложений»:

1. Разработчики могут сосредоточиться только на определенном уровне всей структуры.
2. Заменить исходный уровень реализации на новую реализацию легко.
3. Может уменьшить зависимость между слоями.
4. Способствует стандартизации.
5. Облегчить повторное использование различных уровней логики

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

сцены, которые будут использоваться:

• Новые приложения, которые нужно создавать быстро
• Приложения, требующие строгих стандартов ремонтопригодности и тестируемости

Аккуратная архитектура

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

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

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

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

Шестиугольная архитектура

Гексагональная архитектура также известна как «архитектура адаптера порта».

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

Гексагональная архитектура делит систему на два уровня : внутренний шестиугольник и внешний шестиугольник . Функции этих двух слоев разделены:

• Шестиугольник в красном кружке реализует основную бизнес-логику приложения;
• Внешний шестиугольник завершает взаимодействие и доступ к внешним приложениям, драйверам и базовым ресурсам.Он предоставляет услуги в форме активной адаптации API для интерфейсных приложений и реализует доступ к ресурсам, полагаясь на инверсию и пассивную адаптацию для базовых ресурсов .

Многоуровневая архитектура DDD против аккуратной архитектуры против гексагональной архитектуры

Сравнение и анализ трех моделей микросервисной архитектуры

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

 

Архитектура, управляемая событиями (EDA)

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

Многие современные приложения приняли дизайн, управляемый событиями. Поскольку управление событиями само по себе является методом архитектуры программирования, а не языком программирования , приложения, управляемые событиями, могут быть созданы на любом языке программирования. Архитектура, управляемая событиями, может минимизировать степень взаимосвязи , поэтому она является идеальным выбором для современной распределенной архитектуры приложений.

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

EDA можно понять с двух сторон:

1. EDA - это архитектурный паттерн , ориентированный на асинхронную связь на основе генерации / потребления . Это в основном контрастирует с традиционными системами синхронизации на основе потоков.
2. EDA - это архитектурная модель, которая принимает события в качестве ядра и предоставляет механизмы для генерации событий, маршрутизации, потребления и обратных вызовов.

Представьте пример событийной архитектуры в смежных областях в процессе страхового андеррайтинга.

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

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

 

 

CQRS ( Сегрегация ответственности за запрос команд )架构

Режим разделения ответственности за запрос команд ( CQRS ) - это режим архитектурной системы, который может разделять команду на изменение состояния модели и запрос состояния модели .

По сути, CQRS - это механизм разделения чтения и записи.

Два пути достижения:

1. Базы данных на обоих концах CQ являются общими, и два конца CQ разделены только на верхнем коде; этот подход дает преимущества разделения чтения и записи нашего кода, лучшего обслуживания и отсутствия согласованности данных. проблема на обоих концах CQ, потому что он использует общую базу данных. Эта архитектура очень практична, не только учитывает строгую согласованность данных, но также позволяет поддерживать код.

 

2. База данных и верхний код на обоих концах CQ разделяются, а затем данные Q синхронизируются стороной C , обычно через событие домена . Существует два метода синхронизации: синхронный или асинхронный . Если вам нужна сильная согласованность на обоих концах CQ , вам нужно использовать синхронизацию; если вы можете принять окончательную согласованность данных на обоих концах CQ , вы можете использовать асинхронный.

 

Шаблон проектирования событий домена в микросервисах

Шаблон проектирования событий домена между микросервисами

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