How to avoid Anemic Domain Models and maintain Separation of Concerns?

Question

It seems that the decision to make your objects fully cognizant of their roles within the system, and still avoid having too many dependencies within the domain model on the dat

Answer 1

"thin models to service layer objects" is what you do when you really want to write the service layer.

ORM is what you do when you don't want to write the service layer.

When you work with an ORM, you are still aware of the fact that navigation may involve a query, but you don't dwell on it.

Lookup tables can be a relational crutch that gets used when there isn't a very complete object model. Instead of things referencing things, you have codes, which must be looked up. In many cases, the codes devolve to little more than a static pool of strings with database keys. And the relevant methods wind up in odd places in the software.

However, if there is a more complete object model, we have first-class things instead of these degenerate lookup values.

For example, I've got some business transactions which have one of n different "rate plans" -- a kind of pricing model. Right now, the legacy relational database has the rate plan as a lookup table with a code, some pricing numbers, and (sometimes) a description.

[Everyone knows the codes -- the codes are sacred. No one is sure what the proper descriptions should be. But they know the codes.]

But really, a "rate plan" is an object that is associated with a contract; the rate plan has the method that computes the final price. When an app asks the contract for a price, the contract delegates some of the pricing work to the associated rate plan object.

There may have been some database query going on to lookup the rate plan when producing a contract price, but that's incidental to the delegation of responsibility between the two classes.