Identifying anemic vs rich models

Now that you've gotten a crash course in DDD, we can start to better articulate the possible weakness in the current bookstore model. In the opening chapter, I called the model anemic, which implies that it is feeble and not strongly representative of the domain we are working in. I didn't really back that up with too much explicit evidence though, so let's dig into how to identify an anemic model.

A major issue with this model, as far as I can see, is that the major entities in the system (Book, BookstoreUser, CreditCardTransaction, and SalesOrder) are implemented as simple case classes that have no functionality on them besides the setting of their attributes. All of the functionality related to dealing with those entities is done in manager actors, which is somewhat similar to services in the DDD lexicon.

Services should be ancillary in a DDD approach, but they appear central in our model, robbing the entities of the functionality related...