Означает ли микросервисные данные «владение» данными «понимание»?

Question

Скажем, «общая картина» субъекта хозяйствования похожа на

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5,
   bar: "something",
   baz: [1.0, -4.3]
}

, но по какой-то причине мы решили, что должны быть foo service, bar service и baz service, которыевладеть соответствующими частями данных таким образом, как

---

{
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5   
}

---

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   bar: "something"
}

---

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   baz: [1.0, -4.304]
}

---

Однако, скажем, что я замечаю в системе то, что

• Данные всегда должны объединяться, а некоторая бизнес-логика применяется для выполнения чего-либо значимого.Существуют отдельные сервисы, вся работа которых заключается в упаковке данных из вышеупомянутых сервисов.
• Вышеупомянутые сервисы должны «понимать» данные друг друга, чтобы выполнять значимую работу со своими собственными данными.Например, барная служба не может просто знать, что «foos - это что-то с идентификатором и другими свойствами, которые мне не нужны для понимания».

Вы бы сказали, что это запах дизайна?

Answer 1

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

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

У Эрика Эванса есть отличная презентация об ограниченных контекстах / микросервисах, которая показывает вам, насколько обширным может быть множество вариантов интеграции.

Answer 2

Это очень маленький контекст :), но, как написано, похоже, что сервисы чрезмерно связаны, потому что им всем нужны все данные друг от друга.

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

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

Answer 3

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

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