SOA/WCF dissecting the system & service boundaries

Question

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

Answer 1

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.