Service Oriented Architecture - Dividing your services

Last week Marcus Mac Innes sent me an email asking me how to divide his services, he also started a blog and posted about his question. His basic scenario was this:

He has two services, UserManagerService and CustomManagerService. The next step is that he wants to relate users to customers, each customer is linked to a user. He is trying to decide whether or not the CustomerManagerService should accept a userid and save that id. Or if he should have a separate service, called AddUserToCustomer or something, that links the two objects together.

I think the answer is to include the user id on the CustomManagerService, it is information about the customer and deserves to be on that service. Knowing that the customer is a certain user id does not give the customer service any inappropriate knowledge of the user service. The CustomManagerService simply knows that to get any user information about this customer that it should call the user service and pass the ID. (This might be done in the CustomManagerService or in whatever is consuming both of these services)

Opinions?

Comments

#1 Woodman on 3.12.2004 at 1:00 PM

I agree with the comment on the inclusion on the customer service. Perhaps you could take this example to the next level and discuss the coarse vs. fine grained parameters with respect to both User and Customer...

#2 Marcus Mac Innes on 3.12.2004 at 1:50 PM

James, I came across the following post a couple of days ago by Ramkumar Kothandaraman entitled "Service Boundaries, Business Services and Data" which I believe addresses this very issue:



http://blogs.msdn.com/ramkoth/archive/2004/03/08/85802.aspx



Marcus

#3 Richard Veryard on 7.21.2004 at 4:18 PM

I have posted a comment on my blog at


http://www.veryard.com/so/2004/07/dividing-your-services.htm



Leave a Comment