Привет всем, меня зовут Йи Ан! Сегодня мы поговорим о многоуровневой архитектуре DDD.

микросервисы Архитектура Есть много видов моделей,Например, Чистая архитектура, CQRS, шестиугольная архитектура и так далее. Хотя каждая модель архитектуры предлагалась в разное время и в разное время.,Но его основная концепция — создать «высокую связность и низкую связанность».,Легко добиться эволюции архитектуры. И появление многоуровневой DDD Архитектура,Сделайте границы Архитектуры более четкими,это вмикросервисы Архитектура Модельсередина,занимает очень важное положение.

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

Чистая архитектура

Чистая Архитектуру также называют «луковой архитектурой». Почему ее называют луковой Архитектурой? Посмотрите на картинку ниже и вы все поймете. Чистая Слои архитектуры подобны ломтикам лука, что воплощает идею многослойного дизайна.

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

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

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

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

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

шестиугольная Архитектура также известна как «Архитектура адаптера порта». Прослеживание истоков микросервисов Архитектура обычно предполагает шестиугольную архитектура。

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

Другими словами, на картинке ниже шестиугольная В архитектуре основная бизнес-логика в красном кружке (Модель приложения и домена) полностью изолирована от внешних ресурсов (включая приложения, веб-приложения, ресурсы базы данных и т. д.) и взаимодействует только через адаптеры. Он решает проблему чередования кода между бизнес-логикой и пользовательским интерфейсом и обеспечивает хорошее разделение внешнего и внутреннего интерфейса. шестиугольная архитектура Зависимости каждого слоя и Чистая Как и архитектура, все они полагаются снаружи внутрь.

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

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

Один порт шестиугольной архитектуры может соответствовать нескольким внешним системам.,Различные внешние системы также могут использовать разные адаптеры.,Адаптер отвечает за преобразование протокола。Это делает приложениепрограммамогут последовательно использоваться пользователями、программа、Автоматизированное тестирование и использование пакетных скриптов.

Что такое многоуровневая архитектура DDD?

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

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

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

1. уровень пользовательского интерфейса

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

1. Прикладной уровень

Уровень приложений представляет собой очень тонкий слой. Теоретически он не должен иметь бизнес-правил или логики и в основном ориентирован на варианты использования и операции, связанные с процессами. Но уровень приложений расположен над уровнем домена. Поскольку уровень домена содержит несколько агрегатов, он может координировать несколько агрегированных сервисов и объектов домена для завершения оркестрации и комбинирования сервисов, а также сотрудничать для выполнения бизнес-операций.

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

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

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

1. Слой домена

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

Уровень предметной области содержит объекты предметной области в модели предметной области, такие как совокупные корни, сущности, объекты значений и службы предметной области.

Здесь я хотел бы, в частности, объяснить взаимосвязь между несколькими объектами предметной области, чтобы вам было более понятно при проектировании уровня предметной области. Прежде всего, бизнес-логика модели предметной области в основном реализуется сущностями и службами предметной области. Сущности будут использовать модель перегрузки для реализации всех связанных бизнес-функций. Во-вторых, вам необходимо знать, что сущности и сервисы предметной области не находятся на одном уровне в реализации бизнес-логики. Когда определенные функции в предметной области не могут быть реализованы одной сущностью (или объектом-значением), в игру вступают сервисы предметной области. объединить агрегированный контент. Несколько сущностей (или объектов значений) для реализации сложной бизнес-логики.

1. базовый слой

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

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

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

Каков наиболее важный принцип многоуровневой архитектуры DDD?

В книге «Реализация доменно-ориентированного проектирования» многоуровневая архитектура DDD имеет важный принцип: каждый уровень может соединяться только с уровнем, находящимся под ним.

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

Так как же нам выбирать? Основываясь на своем опыте, чтобы сделать сервис управляемым, я рекомендую вам принять строгую многоуровневую архитектуру.

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

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

Как многоуровневая архитектура DDD способствует развитию архитектуры?

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

1. Эволюция микросервисной архитектуры

поле Модельсерединаобъектиз Уровни изнутри наружу：Объекты значений, сущности, агрегаты и ограниченные контексты。

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

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

Давайте объединим приведенный выше рисунок и возьмем микросервис 1 в качестве примера, чтобы объяснить процесс эволюции микросервисной архитектуры:

• Когда вы обнаружите, что функция агрегации в микросервисах1 часто используется с высокой частотой,Так что это снижает производительность всей микросервисы1,Мы можем поместить код для агрегации,Сплит из микросервисов1,Независимые как микросервисы2. Таким образом, микросервисы2 могут легко справиться с высокопроизводительными сценариями.
• После того, как бизнес разовьется до определенной степени,,Изменения вы найдете в поле Модель микросервисов3.,Агрегацию d удобнее было бы разместить в поле Модель микросервисов1. В это время вы можете переместить весь код агрегата d в ​​микросервисы1. Если вы определили границы кода между агрегатами во время проектирования,Процесс не будет слишком сложным,Это тоже не занимает много времени.
• Наконец мы нашли,После эволюции Модели и Архитектуры,микросервисы1 уже изначально содержат агрегаты a, b, c, развивается и включает агрегат b、c、Будут новые направления Модели и микросервисы тоже.

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

1. Эволюция сервисов внутри микросервисов

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

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

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

Как трехуровневая архитектура превращается в иерархическую архитектуру DDD?

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

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

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

Так как же нам перейти к многоуровневой архитектуре DDD? Давайте посмотрим на процесс ниже.

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

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

Давайте посмотрим на картинку выше и проанализируем процесс эволюции от трехуровневой архитектуры к иерархической архитектуре DDD.

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

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

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

Еще одно важное изменение происходит между уровнем доступа к данным и базовым уровнем. Доступ к данным трехуровневой архитектуры использует метод DAO; база данных многоуровневой архитектуры DDD и доступ к другим базовым ресурсам используют шаблон проектирования репозитория, и каждый уровень отделяет базовые ресурсы посредством инверсии зависимостей.

Складирование разделено на две части: интерфейс складирования и реализация складирования. Интерфейс складирования размещается на уровне предметной области, а реализация складирования — на базовом уровне. Получается, что общие сторонние наборы инструментов, драйверы Common, Utility, Config и другие общие классы общедоступных ресурсов в трехуровневой архитектуре объединены в базовый уровень.

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

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

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

Давайте посмотрим на картинку выше и проведем анализ этих трех архитектурных моделей на основе диаграммы.

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

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

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

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

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

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

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

Видя это, вы уже догадались о ключе к проектированию среднего уровня и микросервисов? Я даю ответ: разумный многоуровневый дизайн модели предметной области и микросервисов. Так каков твой ответ?

Рассматриваем промежуточную платформу и дизайн микросервисов на основе трех архитектурных моделей.

Объединив общие черты этих трех моделей микросервисной архитектуры, позвольте мне рассказать о некотором опыте проектирования промежуточных платформ и микросервисов.

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

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

1. Китайско-тайваньское строительство должно быть сосредоточено на предметных моделях.

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

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

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

2. Микросервисы должны иметь разумную архитектурную многоуровневость.

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

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

Мы уже знаем метод наслоения микросервисов, но существуют ли иерархические зависимости между микросервисами? Как добиться интеграции сервисов между микросервисами?

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

Микросервисы уровня проекта

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

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

Микросервисы среднего уровня корпоративного уровня

Бизнес-процессы уровня предприятия часто выполняются за счет сотрудничества нескольких микросервисов среднего уровня. Так как же интегрировать микросервисы среднего уровня?

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

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

С таким же успехом мы могли бы позаимствовать термин BFF (Backend for Frontends) и пока называть его микросервисом BFF. Большая разница между микросервисом BFF и другими микросервисами заключается в том, что у него нет модели предметной области, поэтому в этом микросервисе нет уровня предметной области. Микросервисы BFF могут взять на себя основные функции уровня приложений и уровня пользовательского интерфейса, завершить объединение сервисов и оркестровку каждого микросервиса промежуточного этапа, а также адаптироваться к требованиям различных интерфейсов и каналов.

3. Разделение и адаптация приложений и ресурсов

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

Именно из-за такой сильной зависимости между ними, как только мы заменим базовые ресурсы, это окажет большое влияние на приложение, поэтому необходимо разделить приложение и ресурсы.

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

Подвести итог

Сегодня я подробно объяснил Чистую архитектураишестиугольная архитектура и многоуровневое представление DDD Архитектура, подробно объясняется многоуровневое представление DDD Архитектура, оно содержит уровень пользовательского интерфейса、Прикладной уровень、Слой доменаибазовый слой. Посредством этих иерархических подразделений мы можем уточнить функции каждого уровня микросервисов, очертить границы объектов в каждой области и определить методы совместной работы объектов в каждой области. Эта Архитектура не только воплощает в себе потребности проектирования микросервисов и эволюцию Архитектуры, но также хорошо интегрируется в концепцию области Модели, обе они органично сочетаются. Наконец, сравнительный анализ трех моделей микросервисной архитектуры, включая многоуровневую архитектуру DDD. итогиз нихизобщие характеристики,и начнем с общности,Были разобраны несколько ключевых моментов среднего этапа моделирования и проектирования микросервисной архитектуры.