In our case, modifications of an order took place in an entirely different system altogether. Different users, different rules, different technology (COBOL).

As far as I could tell, it was a lot of CRUD with lots of validation at that point.

Again, I’d have to go back to the issue that the original design was plain modeled incorrectly. In other cases where I’ve wanted to consume services from an Entity, the Entity knew too much about what was going on.

Even with the Component idea, I still push all behavior related to the entity down to the entity. In the above scenario, I don’t really need to worry about upper layers “knowing” about how to build components, that’s what a factory is for.

As for anemic models, if you can recognize the Inappropriate Intimacy smell when you see it, that alone can create very rich entities.

1. It seems like a fair deal of pain to create a component/service to handle a particular scenario, when you could just be adding a method to an entity.

2. The component solution has a similar drawback to the “Do we really want our callers to have to figure out how the heck to locate an ITaxService or IDiscountCalculator?” problem. Now our callers have to know about this Component in order to conduct usecase x instead of just having the entity do it. For me this part of it is an issue of discoverability.

3. I have a vague feeling that this is drifting towards a manager/anemic domain/transactiony way of doing things. If I write a Component everytime my entity has to *do* something, aren’t I becoming a bit anemic and removing reponsibility from my entity for doing things? Won’t I end up with a bunch of scattered Components all with the responsibility to do one thing? I realize they’re delegating to domain services to do these things, but from the point of view of a caller in an upper layer, I seem to have compromised encapsulation.

In this case, a container call in an entity was a symptom, not the disease. The real problem was bad modeling. There are a few cross-cutting concerns (logging comes to mind) where I might want an IOC container involved, but I would still see these as optional (setter) dependencies rather than opaque or ctor dependencies.

If I really feel like I need a domain service in an entity, it’s probably for a specific scenario. In that case, I’d still go for the component patten, as that would give me a single class that can handle responsibilities for that one scenario.

One nit to pick though. You don’t actually solve the “How do I inject/use a Service/Repository inside an Entity?” problem. You just show that in this case, the entity shouldn’t be doing the work that requires the dependency. In another scenario, your entity may well need a service and you still haven’t shown an alternative to the three options you listed. (FWIW, I consider aspects a fourth and least crappy of the alternatives, but am not happy with any of them.)

In many cases, just the value is just fine. In our case, tax and discounts was quite complex, so it was nice to see right inside our object, the “how” object right there.

That, and we needed more information than just the final discount and tax amount, like the list of discounts and names, the tax reason, etc. Tax and Discounts were value objects themselves, so we didn’t see any point in reducing their value, in our specific case.

I don’t call them entities because they don’t have an identity. If anything, they are closer to Value Objects, but at a much larger scope.

In the Order case, I tried to make the point than in the commerce domain, an Order isn’t something where a taxes and totals are recalculated. Once we found through our conversations with domain experts that a Quote or PotentialOrder is merely a snapshot in time. That would mean it’s not an entity.

It really has nothing to do with injection, but rather why and how these models are used. That I need to do injection is a symptom of a deeper modeling problem.

I think what I’m saying is… I love you man.