Programmers want to make "good designed", "enterprise like" application. So keeping in mind boxy schema of multitiered application they start to organize code into separate layers like most common DAO,Service and Domain. Very often that way leads to Anemic Domain Antipattern. It's characterized by "dumb" C struct like domain objects without logic in methods.
The mechanism is simple: programmer wants to keep layers separate and dependent only on common interfaces. To reduce wiring and simplify initial development DAO object are connected to Service layer which uses also Domain objects. Service layer is filled by Script like methods, written in procedural style. That way of development is easy at the beginning. So main logic goes to Services "layer" and data operations go to DAO layer. After some time Services become really fat, but domain objects gain only more attributes and accessor methods. As long as application is a kind of a prototype, or just is small everything works quite good.
But to get more benefits of object oriented programming in future, we need net of more "intelligent" domain objects "talking" to each other, not just logic closed in services layer scripts. At this moment that could only be done by total refactoring, or just by designing from scratch using experience from previous implementation. Just keep in mind mantra encapsulation, reusability, simplicity.
The simplest cure to that antipattern is to design "good wiring" at the begging, to give domain object direct access to DAO layer, and other low level services needed by domain logic. Then, domain can evolve easy into more complex structures, needed by bigger "enterprise" applications.
The mechanism is simple: programmer wants to keep layers separate and dependent only on common interfaces. To reduce wiring and simplify initial development DAO object are connected to Service layer which uses also Domain objects. Service layer is filled by Script like methods, written in procedural style. That way of development is easy at the beginning. So main logic goes to Services "layer" and data operations go to DAO layer. After some time Services become really fat, but domain objects gain only more attributes and accessor methods. As long as application is a kind of a prototype, or just is small everything works quite good.
But to get more benefits of object oriented programming in future, we need net of more "intelligent" domain objects "talking" to each other, not just logic closed in services layer scripts. At this moment that could only be done by total refactoring, or just by designing from scratch using experience from previous implementation. Just keep in mind mantra encapsulation, reusability, simplicity.
The simplest cure to that antipattern is to design "good wiring" at the begging, to give domain object direct access to DAO layer, and other low level services needed by domain logic. Then, domain can evolve easy into more complex structures, needed by bigger "enterprise" applications.
IT Pro Life
No comments:
Post a Comment