C# 具有WCF职责和依赖关系的SOA

我将进入一个新的团队，该团队已经实现了一个使用SOA和WCF的解决方案。这些服务都是非常垂直的，例如：CustomerService、AddressService、AccountService等。为了返回完全填充的对象，这些服务可以通过wcf端点调用另一个服务

有一些非常高级的垂直区域，但在它们下面可以重用许多核心服务逻辑

以下新体系结构的有效性如何：

Web服务是处理远程调用的薄层；它们严格用于通信。真正的功能将在我们称之为“业务或域服务”的东西中实现

域服务职责：

• 用于使用基础架构的参考数据访问/存储库接口
• 调用多个存储库方法以创建完全填充的对象
• 根据复杂的业务规则处理数据
• 调用其他域服务（不必调用WCF）

这将为我们提供可以在特定WCF和SQL Server实现之外进行测试的域服务

web服务重用不同的业务服务似乎是最大的收益，但也是最大的潜在陷阱

• 一方面，该逻辑可以被多个服务重用，从而消除了web服务调用web服务调用web服务的情况
• 另一方面，如果有人更改其中一个程序集，则需要更新多个服务，这可能会破坏多个应用程序

---

人们是否尝试过这种方法并取得了成功？有更好的方法吗？

这是一种有效的方法。更新多个服务的陷阱取决于这些服务之间的密切关系。您是否有这样一个用例：如果客户服务被更新，而地址服务没有更新，那么客户机仍然可以工作，或者更常见的情况是，所有服务都由同一客户机使用，因此应该一起更新。请记住，只有当WSDL更改而不是实现时，服务才会更改。如果您设法不更改前端服务的DataContracts和OperationContracts，则无需担心。

---

您可以研究的一种方法是在proc WCF服务中使用域服务。或者，前端Web服务可以单独使用域管理器/引擎；y分层程序集，这些程序集依次使用存储库。你可以有一个粗粒度的webservice类实现和细粒度的域实体管理器，这些域实体是可移动的和可单元测试的。

乍一看，你遇到的设计听起来像是：一组“聊天服务”，作者用这个词来描述一种情况，在这种情况下

开发人员通过实现 每个 传递一小段数据。 同一反模式的另一种风格 是什么时候实施的 服务以一个健谈的对话框结束 交流微小的信息 信息，而不是组成 像这样的综合文档中的数据 形式

作者继续说：

性能下降，成本高昂 发展是主要后果 这个反模式的。另外,， 消费者必须付出额外的努力 将这些颗粒聚集得太细 为实现任何利益而提供的服务 以及如何 同时使用这些服务

---

你指的是现有的设置？是的，尽管承认只是基于我对有限信息的不完全理解（服务调用其他服务来完全实现对象）。是的，我同意，他们没有抓住重点，这是一团混乱。现在，我正努力让这一切变得易于管理。谢谢你的链接，它让我在需要的时候说服人们。你对我上面概述的方法有什么看法？这并不完美，但我认为这可能是朝着正确方向迈出的一步。啊，喘息-我没有完全理解您已经过渡到另一个方案，“域服务”中的“服务”更像是域驱动设计中的“服务”，而不是“面向服务的体系结构”中的“服务”所以我的回答并不是说你不知道的。您建议的重新设计听起来像是一种教科书式的SOA方法。如果我能想到除了一般的支持之外还有什么可以补充的，我会编辑我的答案，把它包括进去。在对DDD做了更多的研究之后，我最初在上面概述的内容似乎与这种方法一致。感谢您对我当前布局评估的反馈，以及您最后的评论。更新以更好地澄清基于Jeff Sternal评论的前后提案。请回答？