It was a fun experiment that taught me a lot about the C# spec….but otherwise, it just looked wonky after a while.

ar customer = new Customer();
customer.HasBeenCharged(100,shopOwner);

or

customer.HasBeenCharged(new CustomerChargeFees(100,shopOwner));

s.ChargeFeeTo(customer,amount);

Customer will not charge their self, so we need to give this role to correct party. But we still need a method that receive command that reflect the customer state right. I will probably will have IsCharged(amount) in Customer

So if I only call ChargeFeeTo(), and not Amount(), my code compiles, yet the operation is not complete. Can I charge a fee without an amount? Probably not, so I’d want to be explicit in my domain with that.

I will prefer to change to

Customer customer = new Customer();

Shopper s = new Shopper();
s.ChargeFeeTo(customer).Amount(100m);

customer.MadePayment(50m);

We could just as easily deducted the amount from the already-calculated balance, instead of recalculating it each time. The original problem is that it’s expensive to calculate entire swaths of balances, say listing all the customer’s fee’s balances. Or if you want to query on that information, it becomes quite difficult.

@Mark

In another app we had, all customer catalog prices were cached and pre-built, simply because it was too expensive to calculate up-front. We had a bounded context around catalog management, and could use events to notify when certain things changed. Individual prices could then be re-calculated, but now in a domain object format that was centered around price calculation.

The big thing here is that the Fee object is self-consistent. We can give the Fee object things to help calculations, but ultimately we don’t want half-baked operations.