Monday, July 28, 2008

SOA and Anemic Domains

After a conversation with a work college of mine I was amazed to find that many people have not made the mind shift into a SOA way of thinking.

Most are in the 80’s with a pure OO paradigm; it’s a brave new world people, OO and its promise of reuse failed, no one ever reused pure business objects as is, ever.

The unit of reuse has moved from sharing code to delegation of functionality, the artifact of reuse has shifted from the object to the service. Don’t talk about sending objects around, rather keep the objects where they belong and send messages asking a service to perform actions on them.

They shout out, “but you have an Anemic Domain, it’s an anti pattern so you must be wrong”.

Are they suggesting distributed systems that pass around "real" objects, behaviour and all? You should cry out in terror at the thought of using such a system in production.

For an OO purist the domain model is the most important part, but for the enterprise the database is far more important, seen by the fact that many databases far outlive the applications built to access them.

In SOA land your OO business logic is not the only business logic involved here, your services are part of a large interacting web of autonomous services, some wrapping legacy systems, is their business logic any less important.

I say design your services right, services that are self contained, process/capability driven, have de-centralised data and which communicate via well defined messages will lead to deliverable architectures, nobody will care how elegant your business layer is if you never get it done on time.

No comments: