I recently had a discussion with an architect and he was telling me not to use a anaemic domian model and he quoted some links from online gurus. I was intrigued. His way of thinking was very object oriented (often on encapsulation,
polymorphism etc.,) and I wanted him to think that once you move to an enterprise, object orientation becomes small and may be that is why paradigms like SOA, MDA, EDA picked up and seem to answer some of my problems. He was more concerned around the *design* of the application, model but however I believe he needs more of an enterprise perspective.
When it comes to an enterprise, I'm talking about systems developed using paradigms like EDA, SOA etc., I feel that anaemic domain model serves better than domain model. I believe that having my business nouns which is going to be used across all the enterprise "flows" (which realizes my business use cases), I need my domain model to be a simple bag of getter, setter and have my other concerns like notification in case something goes wrong or something of interest happens, or complex business rules move away from my domain. Cluttering the domain model with business logic somehow seems not okay with me (Single Responsibility).
Say I have a Customer entity which is going to be re-used across many of my enterprise flows like online buy using credit
cards, online buy using debit
cards, online buy using internet banking, offline order booking, buying using coupons and many more flows will use my order, customer, order item, card etc., domain model and in each of these flows, the customer has to exhibit different behaviour based on factors which are idiosyncratic to the flows. There may be some behaviours which are specific to the model and some common across the flows (like age of the card holder cannot be more than 150). Also if the behaviour is going to be derived out of the data and only out of the data which the model holds then making it part of the domain makes sense. Again, how sure am I here to tell that this will not change and it will remain in the same way.
Another reason why I would want to separate the rules from the domain is I may want to use the rules in other facets of my enterprise like reporting or batch processing. Now if we entangle the domain with the rules of the domain, I am afraid I will be suffering later in my life to re-use it from a neutral standpoint. Also given the ways of BPMN, BPEL and ESBs, my flow code is separated out from the domain and hence is managed "separately" and any change in the flows or introduction of new flows affects on those flows which orchestrates between exposed functionalities and the underlying domain model.
Yet another reason is that I can maintain the domain model as a uniform model across my enterprise (say a Customer is a Customer wherever he goes) and all flows re-use the same underlying customer model. By doing this, I might eliminate introducing new customers in order processing systems, in fraud systems, in fulfilment systems and later spend so much on unifying these models. Also if I am planning to use a standard canonical model for my enterprise which may comprise of domain models then it makes sense to have the domain model anaemic.
Also, by making a decision as simple as keep the data and logic separate and by introducing various software elements in my enterprise to handle various types of logic like rules, flows, distributed transactions etc, I somehow insist upfront all along the way to the final leaf node of development that the domain model is not polluted with complex code.
To me domain model is like two fighters fighting in the olympic (where they are loaded with fighting strategy, movements, retaliations, country pride, family support), whereas anaemic domain models are like those foot soldiers in a war, where volume is more, strategy is wide and not restricted, there are information and decisions which the foot soldier doesn't have to know or make. However going by this analogy a foot soldier still has to have a fighting strategy, movements, retaliations, etc., but in this case I will perceive the strategy as a micro-strategy. Sorry for my lousy and clumpsy example, but I hope it gives the message.
I'd love to debate on this topic and I'd love to hear what the folks in javaranch has to say.
If you have reached this far, thanks for reading my post patiently.