SOA / WCF解剖系统和放大器;服务边界 [英] SOA/WCF dissecting the system & service boundaries

问题描述

我建立一个系统，该系统将有几个渠道喂养不同的客户端（MonoDroid的，MonoTouch的，Asp.Net MVC中，REST API）

I'm building a system which will have a few channels feeding different clients (MonoDroid, MonoTouch, Asp.Net Mvc, REST API)

我想领养一个SOA archetecture，也试图通过可达性图案采用持久性（http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/）

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/)

我的问题涉及archetecture的设计。如何最有效地将系统分割成大块谨慎从SOA获益。

My question relates to the design of the archetecture. How best to split the system into discreet chunks to benefit from SOA.

在我的模型有一个SystemImplementation从而重新presents系统iteself的安装。而且帐户实体。

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 - 负责管理与实际安装本身，如品牌，流量日志等事情


• 帐户服务 - 负责管理用户资源（媒体，联系人等的网络）

在逻辑上一个新的用户帐户的注册会发生在 AccountService.RegisterAccount 这里的服务可以照顾验证新帐户（用户名受骗检查等），散列PW等等

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 etc

然而，为了通过可触及性来实现持久性我需要新的帐户添加到 SystemImplementation.Accounts 收集它在SystemImplementation服务自动保存（使用NHibernate我可以使用懒人=额外的保证，当我的新帐户添加到集合不会自动加载所有帐户）

However, 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)

要做到这一点我可能会需要创建帐户服务帐户，未保存的实体传递回客户端，然后让客户端调用 SystemImplementation.AssociateAccountWithSystemImplementation

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.AssociateAccountWithSystemImplementation

所以，我不需要从调用了AccountService的SystemImplementation服务（因为这，纠正我，如果我错了 - 是不好的做法）

So that I don't need to call the SystemImplementation service from the AccountService (as this, correct me if I'm wrong - is bad practise)

我的问题是那么 - 我是不正确的拆分系统？如果是这样，我应该如何分割的制度？是否有定义系统应分别针对SOA的方式有任何方法？它是确定从在服务调用WCF服务：

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.AssociateAccountWithSystemImplementation

我很担心，我打算开始构建基于一些反模式的系统，这将晚一点赶上我：）

I'm worried i'm going to start building the system based on some antipatterns which will come to catch me later :)

推荐答案

通过SOA，最难的部分是决定功能的垂直切片。

With SOA, the hardest part is deciding on your vertical slices of functionality.

一般的原则是...

1）你不应该有多个服务谈话的同桌。您需要创建一个服务，涵盖的功能的区域，然后被$ P $触碰那些相同的表pventing任何其他服务严格。

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），与此相反，你也想保持每个垂直切片的窄，因为它可以的（但没有更窄！）。如果你能避免复杂的，深对象图，就更好了。

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.

你怎么切的功能在很大程度上取决于你自己的舒适度。例如，如果你有你的条和你的作者之间的关系，你会受到诱惑，以创建一个对象图，再presents的作者，其中包含了书面公司章程的列表作者。实际上，你会好起来具有作者的对象，从上AUTHORID只是基于ArticleService被AuthorService，并获取能力条对象交付。这意味着你没有更多要对付一个作者每一次构建与文章，评论，消息，权限列表并加载了完整的作者对象图。虽然NHibernate的会延迟加载的这个要求的相关部分，它仍是一个复杂的对象图。

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解剖系统和放大器;服务边界的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！