> But I think you are doing the > right thing by formalizing and exploiting this type of service in > your architecture. You will get reuse, as you point out, and your > definition of services around business information helps align IT > with business on the data side, in addition to the functional side > driven at the higher level.
My experience is that when you use a domain model you already use it to align yourself with the business, in particular it helps you communicate with the domain experts responsible for that area. You could wrap the most important entities in the domain model with services, but you add a lot of complexity and also lose a lot as the associations/rules that are so easy to specify between entities in a model become more difficult when specified in a contract. Plus the resulting services are not really very autonomous, serious pieces of behavior may involve updates to multiple entities. The tradeoff would be worthwhile if you really get the reuse and shared understanding. However my experience has been that the representations of entities like Person or Customer do vary quite a lot, a lot of the detail that I might want for a customer in the CRM service isn't relevant when we're dealing with customers in an finance service. So whilst you would get reuse from using a single representation in the local neighbourhood I've not seen that many situations where single representation of core entities do work nicely accross any significant area. However I'd admit I've never been involved in any sort of effort that tried to make such an approach work by first designing the services/contracts upfront. I'm not suggesting that being able to access key entities between business services isn't useful, I'm just not sure whether the best approach is to go for entity services upfront. I'd also wonder if using entity services almost precludes you using rich domain models? -Colin
