> Might these have been better placed as operations within a single 
> service? In other words, you didn't have 3 different credit risk 
> services, you had 1 credit risk service with multiple operations. 
> One credit service that defined 42 data elements which were exposed 
> in whole or in part by the service operations.
> 
> This may seem pedantic but I think the distinction is valuable. The 
> credit risk data/data model wasn't shared amongst services, but 
> managed by a single service, manipulated by various operations 
> within that service.

I'd set the boundary higher though, whether they are operations on one service 
or multiple services (or multiple resources for that matter) would be less 
important to me than whether I considered them part of the same higher level 
business service. 

Thats probably ultra vague but what I mean is that if I was using the sort of 
approach from Steve Jones' book and in my discussion with the business I find 
out that they consider Credit Risk as part of a higher level Risk 
capability/business service then that might become the logical boundary. We 
might then find a number of Credit Risk service endpoints/REST resources but we 
would at least have a good idea of how they fit into the bigger picture. This 
is the side of SOA that makes most sense to me anyway.

Actually would it be fair to say that granularity and the whole canonical model 
versus specific models (data or domain) are the two issues that people on here 
are most split on?

- Colin

Reply via email to