我正在构建一个系统，它将有几个通道为不同的客户端提供服务（MonoDroid，MonoTouch，Asp.Net Mvc，REST API）
我正在尝试采用SOA架构并尝试采用可达性模式的持久性（http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/）
我的问题与建筑的设计有关。如何最好地将系统拆分为谨慎的块以从SOA中受益。
在我的模型中有一个SystemImplementation，它代表系统iteself的安装。还有一个账户实体。
我最初考虑设计这个的方式是创建服务：
逻辑上，新用户帐户的注册将在AccountService.RegisterAccount中进行，其中服务可以负责验证新帐户（欺骗用户名检查等），散列pw等
但是，为了通过可达性实现持久性，我需要将新帐户添加到SystemImplementation.Accounts集合中，以便自动保存在SystemImplementation服务中（使用nhibernate我可以使用lazy = extra来确保何时我将新帐户添加到集合中，它不会自动加载所有帐户）
为了实现这一点，我可能需要在AccountService中创建帐户，将未保存的实体传回客户端，然后让客户端调用SystemImplementation.AssociateAccountWithSystemImplementation
这样我就不需要从AccountService调用SystemImplementation服务了（因此，如果我错了，请纠正我 - 这是不好的做法）
我的问题是 - 我是否错误地拆分了系统？如果是这样，我应该如何拆分系统？是否有任何方法可以定义系统应该为SOA分割的方式？可以从服务中调用WCF服务：
AccountService.RegisterAccount - ＆gt; SystemImplementation.AssociateAccountWithSystemImplementation
我担心我会开始根据一些反模式开始构建系统，这些反模式会在以后遇到我：）
答案 0 :(得分：2)
你有一个分区问题，但你并不孤单，所有采用SOA的人都遇到了这个问题。如何最好地将我的系统组织或划分为相关部分？
对我来说，Roger Sessions在谈论这个话题时最有意义，像微软这样的人正在大力聆听。
改变我的想法的论文可以在http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf找到，但我真的推荐他的书“简单架构复杂企业”。
在那本书中，他介绍了集理论中的等价关系以及它们与服务契约划分的关系。
简而言之，
制定分区的规则可归纳为五个法则：
分区必须是真正的分区。 一个。项目只存在于一个分区中。
分区必须适合手头的问题。 一个。分区仅在适合问题时最小化复杂性 在手边，例如按颜色组织的服装店几乎没什么价值 客户正在寻找他们想要的东西。
子集数量必须合适。 一个。研究表明，似乎有一个最佳数量的项目 子集，添加更多子集，从而减少每个子集中的项目数 子集，对复杂性影响很小，但减少了数量 子集，因此增加每个子集中的元素数量似乎 增加复杂性。这个数字似乎在3到12之间，有3到5 是最佳的。
子集的大小必须大致相等 一个。子集的大小及其在整个分区中的重要性必须是 大致等同。
子集之间的交互必须是最小的并且定义良好。 一个。复杂性的降低取决于最小化数量和数量 分区子集之间交互的本质。
如果一开始你弄错了，不要过分强调，SOA宣言告诉我们，我们应该重视进化精益而不是追求最初的完美。
祝你好运答案 1 :(得分：1)
使用SOA，最难的部分是决定你的垂直功能。
一般原则是......
1）您不应该让多个服务与同一个表交谈。您需要创建一个包含功能区域的服务，然后严格禁止任何其他服务触及这些相同的表。
2）与此相反，您还希望保持每个垂直切片尽可能窄（但不能缩小！）。如果你能避免复杂的深层对象图，那就更好了。
如何分割您的功能在很大程度上取决于您自己的舒适程度。例如，如果您的“文章”和“作者”之间存在关系，您将很想创建一个代表“作者”的对象图，其中包含作者撰写的“文章”列表。实际上，您最好拥有一个“Author”对象，由“AuthorService”提供，并且能够仅根据AuthorId从“ArticleService”获取“Article”对象。这意味着您不必每次想要处理作者时都构建包含文章，注释，消息，权限和加载列表的完整作者对象图。即使NHibernate会为你延迟加载相关部分，它仍然是一个复杂的对象图。