http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660There are some problems with the services proposed in this post. For example, the "Available Candidates" service appears highly data centric, likely exposing search/data retrieval operations. CRUD interfaces are bad. Moreover, this service would likely have synchronous request-reply interactions in order to retrieve data or perform searches, and that too is bad. The services proposed here are also too fine grained. A number of these services will share business logic and data representation. For example, the "Available Candidates" service and "Register Candidate" service both deal with candidates as part of the Recruitment process. As such the suggested services should be combined into fewer services so that we do not get duplication of business logic and data representation between services. With regards to defining your services, you need to look at the business context. You want your services to have loose coupling and high cohesion. To me it seems you should have a Sales service which supports the business processes around finding available positions for physicians. You should also have a Recruitment service which supports the business processes around finding physicians to fill the roles identified by the Sales service. I know in your example that the Sales department performs the Recruitment function, however in my view of standard business processes, Recruitment is a distinct function quite independent of the Sales function; involving quite distinctly different business processes and concepts. This makes them good candidates for separate services. Since you have a separate credentialling department, I would agree with your assessment that you should have a Credentialling service as well. If anyone is looking for further guidance on SOA design principals, feel free to check out my blog (http://bill-poole.blogspot.com/) . http://ayende.com/3257/an-exercise-in-designing-soa-systems#comment2http://ayende.com/3257/an-exercise-in-designing-soa-systems#comment2Wed, 09 Apr 2008 07:19:56 GMTHis question seems like a question of granularity. SOA can be defined as the underlying services that are then tied together by some business processing layer to form 'business' services for doing work. I personally like the way that you broke the services down into 'smaller' loosely coupled items. The challenge would then be to write a larger business process that maps onto what the business units are doing that utilizes these lower lever bits of work in order to make it 'make sense' to the business. Nice post. Thank you for allowing my $0.02. Joe Campbell http://ayende.com/3257/an-exercise-in-designing-soa-systems#comment1http://ayende.com/3257/an-exercise-in-designing-soa-systems#comment1Tue, 08 Apr 2008 17:46:25 GMT