Avoiding bloated Domain Objects

Posted by djcredo on Programmers See other posts from Programmers or by djcredo
Published on 2011-11-22T11:35:38Z Indexed on 2011/11/23 2:07 UTC
Read the original article Hit count: 197

We're trying to move data from our bloated Service layer into our Domain layer using a DDD approach. We currently have a lot of business logic in our services, which is spread out all over the place and doesn't benefit from inheritance.

We have a central Domain class which is the focus of most of our work - a Trade. The Trade object will know how to price itself, how to estimate risk, validate itself, etc. We can then replace conditionals with polymorphism. Eg: SimpleTrade will price itself one way, but ComplexTrade will price itself another.

However, we are worried that this will bloat the Trade class(s). It really should be in charge of its own processing but the class size is going to increase exponentially as more features are added.

So we have choices:

  1. Put processing logic in Trade class. Processing logic is now polymorphic based on the type of the trade, but Trade class is now has multiple responsibilites (pricing, risk, etc) and is large
  2. Put processing logic into other class such as TradePricingService. No longer polymorphic with the Trade inheritance tree, but classes are smaller and easier to test.

What would be the suggested approach?

© Programmers or respective owner

Related posts about object-oriented

Related posts about design