I was recently introduced to the notion of Anemic Objects while discussing schema first or POJO first xml definition. I come from the camp of schema first and considered the resulting java objects to be just a normal side effect from this approach. The alternative has scary ramifications from a system design/interoperability perspective.
Before I get into my thoughts on either approach, lets cover what an anemic object is. According to Martin Fowler, they’re an anti-pattern.
The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together.
The service, or business, objects are responsible for extracting the required bits and performing everything from validation to the actual business logic.
So is schema-first really a cause for this problem? Casually speaking, yes, but I believe it’s mostly due to the ease of code gen and focus on ease of development. For most developers, learning WS-Schema is not a simple undertaking, just like learning any language or standard. If I know Java, and a tool will create the required artifacts for me, then I can ignore what’s generated as long as it keeps in sync with my domain model.
Keeping in sync with a domain model can be challenging when a developer doesn’t control the underlying schema. Think about experiences of mapping a robust database schema to an object model. The relational/object impidence has resulted in numerous frameworks, Hibernate, JDO, JPA, EJB, Toplink and many more, to handle these differences. Even then, all allow for a way to just use plain SQL and do the mapping yourself. The same mismatch applies to XML Schema as well. There are various frameworks, JAXB and XMLBeans for example, that help out in this area as well.
It’s easier to allow the Domain Model to drive these models or to just consider any schema-first output as a second class object or bit bucket. I’ll admit to subscribing to the latter. As an enterprise architect, it’s easier to think in terms of data schema and service endpoints that act on it. WS-* and REST both encourage this type of behavior. For the developer on the ground, this can be limiting as it does not help promote OO design.
Indeed often these models come with design rules that say that you are not to put
any domain logic in the the domain objects.
But it doesn’t have to be that way.
I’ll pick on the automated build process for a moment. I think what happens is that the auto-gen of either Schema or POJO gets baked into the build process and developers forget. The output is a secondary though that is constantly sync’d with their domain. The problem is that those external parties that rely on those artifacts are also treated as second class. A developer changes and external interface contract without even thinking. This is the part that is scary
The middle ground is to use the schema gen once and lock it down. Put it in the repository and protect it with the walls of governance. The auto-gen can still place, but it needs to also verify that it has not broken the contract. This way, a schema that started from a POJO and given an official approval as the external interface is protected form unwarranted change, and the developer is granted the ability to grow the POJO into the rich domain model they want.
This approach places constraints on the evolution of a domain object so it’s not recommend that some time be taken to get the domain object as close to the use case/user story as possible. Any evolution will be quickly detected and signal integration or legacy concerns immediately.
Anemic models can be address with a slight change in build process and a stronger embrace of the binding tools that typically generate them.