Резюме

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

код инженерного сооружения

Представлено в предыдущей статьеLandable DDD (2) — почему инженерная архитектура MVC устарелаМногие друзья оставили сообщение, мол есть пример кода, или он слишком сырой, а я не очень хорошо в нем разбираюсь. Напишите образец здесь.

Возьмите сайт блога в качестве примераpage1: Страница со списком блогов:Показать все опубликованные пользователями блоги

page2:Страница профиля: содержит профиль и список блогов.

page3: страница сведений о блоге.

Поля пользователей/блогов, отображаемые разными компаниями, несовместимы.

моделирование

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

Архитектура MVC

Код, написанный в режиме mvc, дописан до конца. См. конкретный кодmvc-structure

DDD

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

MVC VS DDD

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

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

Например, если бизнес изменился, статистика количества блогов в [Личном центре] — это статьи, опубликованные пользователем. И эта публикация может содержать несколько значений по мере развития бизнеса.

1. После того, как пользователь закончил писать, он открыт для публики.
2. Пройден операционный аудит
3. Блоги не подлежат обратимому удалению. Эта логика повлияет на связанные запросы, и реализация этой логики может быть выполнена на уровне базы данных, в Redis или другими способами. В методе написания MVC есть много мест, которые нужно доработать.В методе DDD, как бы ни менялась логика, другие поля знать не нужно, знает только поле блога, и только код в поле блога нужно изменить.

Микросервисное подразделение

первое издание

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

1. Правило «Один домен — одна услуга»разделять,
2. При этом для обеспечения чистоты поля различаемДоменные службы и службы приема и размещения. Доменные службы представляют собой логику домена и не доступны непосредственно внешнему интерфейсу. Внешние службы собирают различные доменные службы и предоставляют их внешнему интерфейсу.
3. в то же времяПродолжать расширяться, мы резервируем микросервис в качестве сервисного инкубатора. Для тех, у кого неясные поля (например, для большинства новых предприятий), они инкубируются в этой услуге, а затем разделяются, когда поле становится достаточно большим.

Как показано ниже

Приложение переднего плана: ПК: отображение страницы на стороне ПК мобильный: отображение мобильной страницы mini: отображение страницы апплета

Доменные службы: блог: Поле блога пользователь: пользовательское поле рост: полевой инкубатор

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

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

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

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

Как решить

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

Связанное Чтение Landable DDD(1) - Обсуждение цели

Landable DDD (2) — почему инженерная архитектура MVC устарела

Landable DDD (3) — Как использовать DDD для разделения микросервисов

Обратите внимание на [Храм аббата], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом.