SOA/WCF dissecting the system & service boundaries_问答_开发者

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 etc
AccountService - 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 etc

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)

For this to happen I'd probably need to create the Account in AccountService, pass back the unsaved entity to the c开发者_如何学运维lient and then have the client call SystemImplementation.AssociateAccountWithSystemImplementation

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)

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

You have a partitioning issue, but you are not alone, everyone who adopts SOA comes up against this problem. How best to organize or partition my system into relevant pieces?

For me, Roger Sessions is talking the most sense around this topic, and guys like Microsoft are listening in a big way.

The papers that changed my thinking in this can be found at http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf, but I really recommend his book Simple Architectures for Complex enterprises.

In that book he introduces equivalence relations from set theory and how they relate to the partitioning of service contracts.

In a nutshell,

The rules to formulating partitions can be summarized into five laws:

Partitions must be true partitions. a. Items live in one partition only, ever.
Partitions must be appropriate to the problem at hand. a. Partitions only minimize complexity when they are appropriate to the problem at hand, e.g. a clothing store organized by color would have little value to customers looking for what they want.
The number of subsets must be appropriate. a. Studies show that there seems to be an optimum number of items in a subset, adding more subsets, thus reducing the number of items in each subset, has very little effect on complexity, but reducing the number of subsets, thus increasing the number of elements in each subset seems to add to complexity. The number seems to sit in the range 3 – 12, with 3 – 5 being optimal.
The size of the subsets must be roughly equal a. The size of the subsets and their importance in the overall partition must be roughly equivalent.
The interaction between the subsets must be minimal and well defined. a. A reduction in complexity is dependent on minimizing both the number and nature of interactions between subsets of the partition.

Do not stress to much if at first you get it wrong, the SOA Manifesto tell us we should value Evolutionary refinement over pursuit of initial perfection .

Good luck

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.