> This seems like a reasonable approach. I'm curious, how do you > reconcile the idea of "anemic data services" that Martin Fowler > talks about here: > http://martinfowler.com/bliki/AnemicDomainModel.html (pointed out in > Colin K's post)? Is there merit to his argument?
Fowler is talking about how your domain model can be anemic if all the logic moves into services, so if you do choose to have a domain model then you want to ensure you get your monies worth by ensuring that the resulting casses are behaviour rich. On top of these behavior rich classes you'll probably have services, which provide valuable services such as mapping/messaging/coordination and so on. So I definitely think theres merit in his arguments and I think domain models are a superb way to go, but a domain model based approach to solving complex problems does seem to be at odds with some of what Erl is proposing regarding entity services. > With this approach (isolated entity services), you miss the > opportunity for reuse. Maybe this is not a big deal... you can > measure the benefit of reuse by how much work you save. If its easy > to get the data, the reuse benefit is small and so this is a > secondary issue. But, if data is complex, as in most enterprises > (multiple phyiscal data sources for a logical entity, relational and > non-relational, duplicated, dirty, etc), then reuse becomes > important, often critical in terms of lifecylce support (not just > initial development). I guess I question the reuse angle. Other than CRUD the behaviour that the entities need to take on in particular contexts varies, in a CRM system my Customer does one thing and in a Finance system it does something incredibly different. That's handled by Erl talking about keeping the entity services agnostic but in the process I think you lose a lot of the value. Sharing the data I get, that's valuable. However I can handle that by just exposing extra interfaces to the business services, so you could ask a CRM service for a Customer. If this was proving valuable then I can see that you'd want to have a Customer.xsd as Erl suggests. However I'd be surprised if you'd need this for many entities, as many entities only make sense in a few contexts (for example Policy miught have has no reason to show up in a CRM system). Even for something like Customer one of Erl's aims is to avoid transformations, but I'd question the whole idea of sharing one representation of an entire entity. Does it really work, does the resulting representation not end up being very clunky? > If its easy to get the data, the reuse benefit is small and so this > is a secondary issue. But, if data is complex, as in most > enterprises (multiple phyiscal data sources for a logical entity, > relational and non-relational, duplicated, dirty, etc), then reuse > becomes important, often critical in terms of lifecylce support (not > just initial development). Definitely, and I'm not saying you don't need an SOA (or services at the least). I'm just wondering if entity services are a good solution. -Colin Jack
