Мы внедряем SOA-архитектуру способом Udi Dahan, что означает, что сервисы являются автономными компонентами, ориентированными на бизнес (у нас мало сервисов, каждый из которых является частью домена, и им не разрешено вызывать друг друга).Мы используем nservicebus pub / sub.Я пытаюсь найти лучший способ справиться с «сквозными» проблемами данных.
Позвольте привести пример:
У нас есть игровой сервис, который пользователь может использовать для игр.У игр есть крайние сроки, и мы хотим предупредить их, отправив пользователю письмо по электронной почте.Почта будет содержать данные из нескольких служб.Теперь, поскольку сервисы не могут вызывать другие сервисы, я вижу несколько разных подходов:
1) Обрабатывать это в игровом сервисе
Публиковать достаточно сообщений от других сервисов, чтобы игра-служба может хранить свою собственную версию данных, в которой она нуждается, и поэтому ей не нужно зависеть от данных других служб, когда она хочет составить почту.
Минусы:
-Больше сообщений необходимобыть опубликованным - Денормализация данных - Суетливое владение данными (один факт в нескольких местах) - Громоздко добавлять новые данные в почту (больше сообщений, хранить вещи в игровом сервисе)
2) Создать агрегированиесервис.
Создание агрегирующего сервиса, который будет прослушивать события сервиса, хранить все, что нужно для создания почты, и запускать его, когда игровой сервис сообщает, что крайний срок заканчивается.
Минусы:
-Довольно то же самое, что и 1), но владение данными намного яснее
3) Создать клиента
Создать "cli"ent "(у этого клиента не будет графического интерфейса и он будет размещен на nservicebus, почти так же, как сервис, но и что-то совсем другое).Клиент подпишется на bus-события и, как 2), получит уведомление от игрового сервиса, когда крайний срок истекает.Клиент будет составлять почту, запрашивая службы, необходимые для сбора необходимой информации.
Минусы:
-Служба клиента (нечеткая архитектура) -Все, что нужно для составления письма, должно быть запрашиваемым (незащищенным)
Как вы это делали в своем замечательном пабе/ sub архитектура SOA в стиле Udi?: -)