микросервисный общий домен - PullRequest
0 голосов
/ 08 мая 2018

У меня есть сомнения по поводу архитектуры микросервисов. Мы разрабатываем ERP, и есть несколько микросервисов, таких как Управление персоналом, Идентификация, Заказы и так далее.

Мы реализовали слой общего домена для сущностей, которые являются общими для всех этих уровней, включая абстракции (интерфейсы) Company, Location и некоторые объекты-значения.

Мой вопрос: какова граница общих элементов для микросервисов и насколько это плохо?

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

Ответы [ 2 ]

0 голосов
/ 10 мая 2018

Мой вопрос: какова граница общих элементов для микросервисов и насколько это плохо?

Еще несколько лет назад было сложно определить границы, определяемые микросервисом, потому что просто не было соглашения о том, как это архивировать, но Эванс разобрался с этим несколько лет назад:

GOTO 2015 • DDD & Microservices: наконец, некоторые границы! • Эрик Эванс

Микросервисы также следуют четырем арендаторам SOA, и те же 9 ошибок распределенной системы должны быть приняты во внимание, тем не менее, их бизнес-сферы различны. Имейте в виду, что микросервисная архитектура должна следовать архитектуре типа Shared-nothing, поэтому сервисы на самом деле не делятся объектами, поэтому они подписываются на сообщения, как правило, на шине, и хранят локальные копии фрагментов данных, которыми они являются. Заинтересованы. Это, очевидно, вводит другую концепцию, называемую возможной последовательностью и зависящей от требований вашего бизнеса, которая может или не может быть, если в вашем общем дизайне.

0 голосов
/ 08 мая 2018

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

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

Если придерживаться темы «ERP», можно ожидать, что контекст «Размещение заказа» в вашем приложении будет иметь совершенно иной взгляд на сущность «Продукт», чем контекст «Налога». Хранение их в разных контекстах в разных базах кода позволит вам моделировать меньшие агрегаты с более высоким уровнем связности, которые будут намного менее связаны с другими конструкциями вашей модели, что упрощает развитие ваших микросервисов.

...