SOA/WCF 剖析系统和服务边界

Question

我正在构建一个系统，该系统将有几个通道为不同的客户端提供数据（MonoDroid、MonoTouch、Asp.Net Mvc、REST API）

我正在尝试采用 SOA 架构，并尝试采用可达性模式的持久性 (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/)

我的问题与架构的设计有关。如何最好地将系统拆分为离散的块以从 SOA 中受益。

在我的模型中有一个 SystemImplementation 代表系统本身的安装。还有一个 Account 实体。

我最初设计它的方式是将服务创建为：

• SystemImplementationService - 负责管理与实际安装本身相关的事情，例如品牌、流量记录等
• AccountService - 负责管理用户资产（媒体、联系人网络等）

从逻辑上讲，新用户帐户的注册将发生在 AccountService.RegisterAccount 中，服务可以负责验证新帐户（重复的用户名检查等）、散列密码等

但是，为了通过可访问性实现持久性，我需要将新帐户添加到 SystemImplementation.Accounts 集合中，以便它自动保存在 SystemImplementation 服务中（使用 nhibernate 我可以使用lazy=extra 来确保我添加将新帐户添加到集合中，它不会自动加载所有帐户）

为此，我可能需要在 AccountService 中创建帐户，将未保存的实体传回给客户端，然后让客户端调用 SystemImplementation.AssociateAccountWithSystemImplementation

这样我就不需要从 AccountService 调用 SystemImplementation 服务（这样，如果我错了，请纠正我 - 是不好的做法）

然后我的问题是 - 我是否错误地拆分了系统？如果是这样，我应该如何拆分系统？是否有任何方法来定义系统应该为 SOA 拆分的方式？是否可以从服务中调用 WCF 服务：

AccountService.RegisterAccount --> SystemImplementation.AssociateAccountWithSystemImplementation

我担心我会开始基于一些反模式构建系统，这些反模式稍后会抓住我:)

Answer 1

你有一个分区问题，但你并不孤单，每个采用 SOA 的人都会遇到这个问题。如何最好地将我的系统组织或划分为相关的部分？

对我来说，Roger Sessions 谈论这个话题最有意义，像微软这样的人正在认真倾听。

在这方面改变我想法的论文可以在http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf 找到，但我真的推荐他的书《复杂企业的简单架构》。

在那本书中，他从集合论中介绍了等价关系以及它们如何与服务合同的划分相关。

简而言之，

制定分区的规则可以概括为五个规律：

1. 分区必须是真正的分区。 一种。项目永远只存在于一个分区中。

2. 分区必须适合当前的问题。 一种。分区仅在适合问题时才最小化复杂性 手头，例如一家按颜色组织的服装店没有什么价值 客户正在寻找他们想要的东西。

3. 子集的数量必须合适。 一种。研究表明，似乎有一个最佳项目数 子集，添加更多子集，从而减少每个子集的项目数 子集，对复杂度的影响很小，但减少了 子集，因此增加每个子集中的元素数量似乎 增加复杂性。这个数字似乎在 3 – 12 范围内，其中 3 – 5 是最优的。

4. 子集的大小必须大致相等 一种。子集的大小及其在整个分区中的重要性必须是 大致相当。

5. 子集之间的交互必须最小且定义明确。 一种。复杂性的降低取决于最小化数量和 分区子集之间交互的性质。

如果一开始你就弄错了，不要过分强调，SOA 宣言告诉我们，我们应该重视进化的细化而不是追求最初的完美。

祝你好运

Answer 2

对于 SOA，最困难的部分是确定您的垂直功能切片。

一般原则是......

1) 您不应该让多个服务与同一个表通信。您需要创建一个包含某个功能区域的服务，然后通过防止任何其他服务触及这些相同的表来严格执行。

2) 与此相反，您还希望保持每个垂直切片尽可能窄（但不能更窄！）。如果您可以避免复杂、深层次的对象图，那就更好了。

如何划分功能很大程度上取决于您自己的舒适度。例如，如果您的“文章”和“作者”之间存在关系，您会很想创建一个表示“作者”的对象图，其中包含作者撰写的“文章”列表。实际上，您最好拥有一个由“AuthorService”提供的“Author”对象，以及仅基于 AuthorId 从“ArticleService”获取“Article”对象的能力。这意味着您不必在每次要与作者打交道时构建包含文章、cmets、消息、权限和加载更多列表的完整作者对象图。尽管 NHibernate 会为您延迟加载相关部分，但它仍然是一个复杂的对象图。