Great article, well written. I've been chewing over this topic for about ten years now. At various times my opinions change, I get new insight due to problems encountered in new business domains.
One of the largest blockers I see to the use of good design are large enterprise systems. Multi-national companies may want a common object foo, but foo.makepayment() means a different implementation in each national office. This complexity encourages an anaemic approach. It's far easier to create a central payment service which processes an anaemic foo and applies regional logic flow, than own fifty versions of foo.makepayment().
The constraint on leveraging good design appears to be scale and ownership of business rules.
That is a quite interesting question.
It would be nice if anyone could suggest an approach to this scenario that favours the rich model over the anemic one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Ka,
Great article, well written. I've been chewing over this topic for about ten years now. At various times my opinions change, I get new insight due to problems encountered in new business domains.
One of the largest blockers I see to the use of good design are large enterprise systems. Multi-national companies may want a common object foo, but foo.makepayment() means a different implementation in each national office. This complexity encourages an anaemic approach. It's far easier to create a central payment service which processes an anaemic foo and applies regional logic flow, than own fifty versions of foo.makepayment().
The constraint on leveraging good design appears to be scale and ownership of business rules.
Thanks
Paul
Hi Paul,
That is a quite interesting question.
It would be nice if anyone could suggest an approach to this scenario that favours the rich model over the anemic one.