我们正在开发一些服务，PersonService比如说InsuranceService和PaycheckService。要通过 API 访问这些服务，有一个控制器。
在某些情况下，PaycheckService需要有关 a的信息Person。目前我们正在使用一个介于Controller和之间的层Service：
目前正在工作，但随着更多服务的创建，服务之间的依赖性增加。这会在这个“层间”中产生更多的逻辑（魔术？） 。
我一直在阅读 Fowler 关于依赖注入和服务定位器的主题，这可能很有用。（我们在这里和那里使用 Unity 来实现 IoC 和 DI 以实现共享功能）
问题是让服务消费其他服务的好策略是什么？
（消息传递、注入、REST、..）
您的服务应该是自治的。他们不应该互相交流。你应该认为每一项服务都是一个完全独立的产品，可以在其他项目中使用，或者它可以为其他公司服务于不同的目的。
如果 ServiceY 需要来自 ServiceX 的一些数据，ServiceY 应该获取该数据作为输入，它不应该连接其他服务来获取数据。
你可以在你的服务前面放置一个门面（或多个门面）来编排你的服务。这个外观实际上将是您的应用程序的高级业务，包括工作流，例如首先从 ServiceY 获取数据，然后将该数据提供给 ServiceX 并从 X 获取结果等。
如果您的服务不是 Web 服务，而只是应用程序业务层中的组件，那么它们应该是自治的并且不应该相互使用，而 Controller 可以作为您编排服务组件的外观。
您可以创建一个组件，该组件负责根据它提供的合同来促进服务的定位。
这样一个服务只需要知道它想要使用的合约和服务定位器。
定位器可以是任何东西，从从网络共享读取配置列表的类到从持久存储读取配置或使用WS-Discovery跟踪服务的中央服务。
此外，您可能希望创建/设计一组共享的数据合约，以指定服务之间交换的类型/消息。通过这种方式，您可以减轻在服务中使用的类型之间进行转换的负担。
编辑
您添加到您的问题：
（消息传递、注入、REST、..）
要求：快速、松耦合
老实说，我确实认为这个添加不是很有用，因为这些不是策略，而是可以帮助实现设计的模式和工具。
此外，这些要求也不是很有帮助，因为我们不知道您认为什么是快速的，也不知道松散耦合的哪个特性对您最重要。
如果您正在寻找具体的指导，请尝试使问题更具体，或者尝试构建一些东西并就您遇到的问题提出问题。