Разрешить связь между службами?

Question

Мы работаем над рядом услуг, скажем PersonService, InsuranceService и PaycheckService. Для доступа к этим услугам через API есть контроллер.

Бывают ситуации, когда PaycheckService нуждается в информации о Person. В настоящее время мы используем слой между Controller и Service к:

• Получить информацию от PersonService
• Получить информацию от PaycheckService
• комбината и вернуть результат.

Эта работа в данный момент, но при создании большего количества сервисов зависимость между услугами увеличивается. Это приводит к большей логике (магии?) В этом 'между слоем'.

Я читал Фаулер по теме «Инъекция зависимостей» и «Локатор услуг», который может быть полезен. (мы используем Unity для IoC и DI здесь и там для совместной работы)

Вопрос в том, что является хорошей стратегией, позволяющей сервисам использовать другие услуги?

(Messaging, Инъекции, REST, ..)

Answer 1

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

Если ServiceY нуждается в некоторых данных из ServiceX, ServiceY shoud получит эти данные в качестве входных данных, он не будет подключать другие службы для получения данных.

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

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

Answer 2

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

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

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

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

EDIT

Вы добавили к вашему вопросу:

(Messaging, Injection, REST, ..)

Требования: Быстрая, слабосвязанная

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

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

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