Avoiding bloated Domain Objects
- by djcredo
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:
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
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?
