This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
If you are not laughing at yourself, then you just didn't get the joke.
I like the way that architect thinks. Now, if you say he also actively writes tests and production code then he's one of the few whom I'd consider to be a real architect.
SOA and the other "paradigms" that you cited have nothing to do with Rich vs Anemic Domain Models, IMO. As Uncle Bob Martin would say, and I paraphrase: "Those are concerns that are related to the implementation of services that support the domain model." Well, I suppose MDA is an exception to this since it's about modeling, after all. But the point is that a rich domain model opens the door to more options for implementing different architectures. Having more architectural options is important in this day and age, especially with the increasing popularity of BYOD and mobile devices. A rich domain model also affords you greater ability to separate concerns, something that is essential for good architecture and design. The minute you start mixing concerns like SOA and the domain model, you are heading down the road towards unnecessary complexity and pain, IMO.
"Now, if you say he also actively writes tests and production code then he's one of the few whom I'd consider to be a real architect."
-- Yes. He does. We grew up together, I can bet he sure is a good architect. I'd be happy to pass your comment onto him.
We had worked together and while he continued to be in products and domain specific systems space, I moved to understanding enterprises.With this background, we discussed a lot from functional programming to procedural to object oriented, aspect oriented, service oriented. In fact all *-oriented styles and the impact it has on designing the elements of a system. We also discussed domain driven design. In the end neither of us were convinced clearly on which is better and for me personally, looking at it more from an enterprise perspective, I felt anaemic model had an upperhand.
Now my usual architectural style in my model is to have domain, repository strucures and data carriers in the domain context. But, when I switched to enterprise my way of looking at models changed. previously my models used to be rich, with business logic around it. But now, since I want my model to be shared and I started coding all my concerns like authorizations, security, transactions, messaging related, rules, state mgmt, flow mgmt (workflows, bpmn, ESB) mediation/activation, communication related, transformation related etc., separately away from my core domain model, I saw my domain model stripped off and ended up being just core business nouns with getters and setters mostly*. But what was enriching is that the domain model contained rich and comprehensive data attributes and a very good hierarchy of relations. But with no complex behaviour per se. Now, each of these concerns I mentioned above might be based on frameworks which could be developed using OO style has clearly made my domain model anaemic and there by providing rich features of it's own.
I ended up:
Rich domain model (core model + business logic + concerns[??]) = anaemic domain model + frameworks doing business logic and concerns
The following diagram is the end-state what I have in mind regarding enterprise models. I have separated all the concerns here and strictly shown only the model.
To me if we are doing a system with a known boundary on the domain context I would use domain driven model. No if I have to use multiple systems, across contexts, across the enterprise and share models across various heterogenous systems, then I would use the right side of the above equation.
Again pardon me for the dirty picture. I am bad using visio without a mouse in hand. Might not be elaborate, but I believe it quickly depicts what I have in mind.
"SOA and the other "paradigms" that you cited have nothing to do with Rich vs Anemic Domain Models."
-- Here is where I am lost. When I begin to design a SOA based modeling of my enterprise, I end up having my hand on all the spectra in the business domain and I have services doing all the business logic and handling my concerns separately rendering my domain model a snake without fangs.