[twhitmore]

Behaviour is what needs to despatched, and behaviour is what benefits from applying eg. strategy pattern, delegation, orchestration.

Extracting important business behaviour into objects allows applying OO (ie, powerful despatch rules) where it is valuable.

Subtyping your model to achieve many of these possible usecases would give poor design results.

For example, if payment processing were in Payment.process() the Payment entity would need to be subtyped or composed for any of 1) a different payment gateway, 2) a sales tax in a new jurisdiction, 3) a new confirmation, or 4 a new payment flow. Having all that in your model entity is probably wrong.

Simple behaviour is fine in the model, major business TN usually not.

[pydry]

>For example, if payment processing were in Payment.process() the Payment entity would need to be subtyped or composed for any of 1) a different payment gateway, 2) a sales tax in a new jurisdiction, 3) a new confirmation, or 4 a new payment flow. Having all that in your model entity is probably wrong.

There's nothing at all wrong with having, say, a PaymentGateway and SalesTax classes and composing them with Payment in whatever way makes sense given their interdependent relationships. Code that has real life analogs to objects tends to be much cleaner, in fact.