David_W (70) [Avatar] Offline
Are you sure that this is actually something that you would really want to do in the real world? For example, a persisted order that is reloaded into memory a few weeks later should still return the same value for the total price that was obtained at the time that the order was paid. By injecting the pricing strategy, you probably won't get the same value, due to changes in specials, costs, etc.

You also indicate just before 16.1.3 that it seems natural that an order should be able to figure out its own price. Really? It seems to me that pricing is something that should be done by a service. I would think that something safe to do in an order object is to make the order responsible for persistence of orders, so an order contains a field for the order repository, and contains methods to do searches, saves, etc.
ramnivas (171) [Avatar] Offline
Re: question about example of domain DI for getTotalPrice in 16.1.2
Actually, in this scenario getTotalPrice() in Order (delegated to a pricing strategy) will be better in many respect. The implementation of getTotalPrice() could check for "frozen" order. If the order is frozen, it will return the persisted value of total price. If not, it will delegate to the strategy to compute (and may update the persisted value of total price).

When I say an order should be able to figure out its own price, I don't necessarily mean that it must include the logic in place. In fact, as the examples show, I use a pricing strategy (a service) to compute the price. The important thing is that the Order class be in control--it can compute itself, it can conditionally delegate (the frozen order scenarios earlier), or always delegate to another object/service. From the external perspective, how order computes the price is irrelevant.