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

我的问题与架构设计有关.如何最好地将系统拆分为谨慎的块以从 SOA 中受益.在我的模型中有一个 SystemImplementation，它代表系统本身的安装.还有一个 Account 实体.我最初考虑的设计方式是将服务创建为:SystemImplementationService - 负责管理与实际安装本身相关的事情，例如品牌塑造、流量记录等AccountService - 负责管理用户资产(媒体、联系人网络等)逻辑上，新用户帐户的注册将发生在 AccountService.RegisterAccount 中，该服务可以负责验证新帐户(重复用户名检查等)，散列密码等但是，为了通过可达性实现持久性，我需要将新帐户添加到 SystemImplementation.Accounts 集合中，以便它自动保存在 SystemImplementation 服务中(使用 nhibernate 我可以使用 lazy=额外确保当我将新帐户添加到集合时它不会自动加载所有帐户)为此，我可能需要在 AccountService 中创建帐户，将未保存的实体传回给客户端，然后让客户端调用 SystemImplementation.AssociateAccountWithSystemImplementation这样我就不需要从 AccountService 调用 SystemImplementation 服务(因此，如果我错了，请纠正我 - 是不好的做法)我的问题是 - 我是否错误地拆分了系统?如果是这样，我应该如何拆分系统?是否有任何方法可以定义系统应该为 SOA 拆分的方式?是否可以从服务中调用 WCF 服务:AccountService.RegisterAccount --> SystemImplementation.AssociateAccountWithSystemImplementation我担心我将开始基于一些反模式构建系统，这些反模式稍后会抓住我:) 解决方案 对于 SOA，最难的部分是决定功能的垂直切片.一般原则是...1) 您不应该让多个服务与同一张桌子交谈.您需要创建一个包含某个功能领域的服务，然后严格防止任何其他服务接触这些相同的表.2) 与此相反，您还希望保持每个垂直切片尽可能窄(但不能更窄！).如果你能避免复杂的、深层次的对象图，那就更好了.如何划分功能在很大程度上取决于您自己的舒适度.例如，如果您的文章"和作者"之间存在关系，您将很想创建一个代表作者"的对象图，其中包含作者撰写的文章"列表.实际上，您最好拥有一个由AuthorService"提供的Author"对象，并且能够根据 AuthorId 从ArticleService"中获取Article"对象.这意味着您不必在每次想要处理 Author 时构建一个包含文章、评论、消息、权限和加载更多列表的完整作者对象图.尽管 NHibernate 会为您延迟加载相关部分，但它仍然是一个复杂的对象图.I'm building a system which will have a few channels feeding different clients (MonoDroid, MonoTouch, Asp.Net Mvc, REST API)I'm trying to adopt an SOA archetecture and also trying to adopt the persistence by reachability pattern (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/)My question relates to the design of the archetecture. How best to split the system into discreet chunks to benefit from SOA.In my model have a SystemImplementation which represents the an installation of the system iteself. And also an Account entity.The way I initially thought about designing this was to create the services as:SystemImplementationService - responsible for managing things related to the actual installation itself such as branding, traffic logging etcAccountService - responsible for managing the users assets (media, network of contacts etc)Logically the registration of a new user account would happen in AccountService.RegisterAccount where the service can take care of validating the new account (duped username check etc), hashing the pw etcHowever, in order to achieve persistence by reachability I'd need to add the new Account to the SystemImplementation.Accounts collection for it to save in the SystemImplementation service automatically (using nhibernate i can use lazy=extra to ensure when i add the new account to the collection it doesn't automatically load all accounts)For this to happen I'd probably need to create the Account in AccountService, pass back the unsaved entity to the client and then have the client call SystemImplementation.AssociateAccountWithSystemImplementationSo that I don't need to call the SystemImplementation service from the AccountService (as this, correct me if I'm wrong - is bad practise)My question is then - am i splitting the system incorrectly? If so, how should I be splitting a system? Is there any methodology for defining the way a system should be split for SOA? Is it OK to call a WCF service from in a service:AccountService.RegisterAccount --> SystemImplementation.AssociateAccountWithSystemImplementationI'm worried i'm going to start building the system based on some antipatterns which will come to catch me later :) 解决方案 With SOA, the hardest part is deciding on your vertical slices of functionality.The general principles are...1) You shouldn't have multiple services talking to the same table. You need to create one service that encompasses an area of functionality and then be strict by preventing any other service from touching those same tables.2) In contrast to this, you also want to keep each vertical slice as narrow as it can be (but no narrower!). If you can avoid complex, deep object graphs, all the better.How you slice your functionality depends very much on your own comfort level. For example, if you have a relationship between your "Article" and your "Author", you will be tempted to create an object graph that represents an "Author", which contains a list of "Articles" written by the author. You would actually be better off having an "Author" object, delivered by "AuthorService" and the ability to get "Article" object from the "ArticleService" based simply on the AuthorId. This means you don't have to construct a complete author object graph with lists of articles, comments, messages, permissions and loads more every time you want to deal with an Author. Even though NHibernate would lazy-load the relevant parts of this for you, it is still a complicated object graph. 这篇关于SOA/WCF 剖析系统&服务边界的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！