Domain Model, Anemic Domain Model and Single Responsibility Rule

PHP
1

Well I was wondering how domain models are supposed to be designed in a way that it does not behave like an anemic domain model, nor does it violate single responsibility principle. As far as I know, many PHP frameworks such as CakePHP use Anemic Domain Model, in which the models do not have any behaviors other than getter/setter. This is considered an anti-pattern according to Martin Fowler and therefore should be avoided. Many advanced/professional programmers advocate for fat model - thin controller design strategy, and thats for a reason.

Unfortunately, real life is not all that simple, a fat model can quickly become uncontrolled and end up violating single responsibility principle. In fact my first domain model designed 2 years ago had even controller and presentation logic in it, it may sound laughable but it does happen. Stripping responsibilities from fat domain models, however, will eventually lead to anemic domain model. Its a difficult balance.

In fact, someone on stackoverflow used an example to illustrate that the balance can be found. The problem is, he uses a typical OO example, a car, something you typically find in a beginner OO textbook. Personally I dont consider this a good example as in most web/enterprise applications, you dont use cars, dogs or such simple objects for your models. They may be good to initialize beginner coders OO thought process, but almost never useful in real applications. Having a car/dog as example for explaining complex concept can be confusing. Instead, I wonder what a User, UserProfile, Item or Shop domain object’s single responsibility should be…
http://stackoverflow.com/questions/8808314/how-single-responsibility-principle-relates-to-anemic-rich-domain-model

So I’d like to ask you advanced programmers here, according to single responsibility principle, what specific responsibility does your domain model have? And what are the reasons for this? A concrete and example from an actual web application would be nice(not something like a car, a dog that you never use in domain model design), thanks.

2

I’m not sure I fully understand your question here. Can you provide some code examples of the issues you are facing?

It’s usually quite easy to adhere to SRP providing you’re using Dependency Injection correctly and not Digging into Collaborators

Correct me if I’m wrong but you’re acting as if the “Domain model” is a single object within the system? (Or perhaps a single object within a specific MVC triad? either way…) that’s not the way to think of it. The term “domain model” never refers to a single class but any number of classes required to represent the domain (In simple scenarios it can still be one, of course)

3

Well the question is how to design a domain model that satisfy both the two criteria: Not anemic domain model, following single responsibility principle.

In my current design I am applying a data mapper class to carry out CRUD operations on domain models, and then there is a dilemma. The domain model contains behaviors that are actually controller/presentation logic, but factoring them further out will leave the domain model anemic in many cases. I wonder if anyone of you have experienced the same problem before, for me its quite common.

4

In Symfony, for example, the domain is split into two kinds of objects: entity classes and repository classes.

The entity classes don’t know about the database nor the larger application. In theory, the collection of entity classes could be taken as a standalone library that could be used in any framework or no framework. They can take on as much responsibility as they can within those limitations. So, for example, hashing the user’s password or checking the user’s roles could be handled here.

The repository classes know about the database and entities but are otherwise ignorant of the larger application. So, for example, checking if a username is available would be handled here.

That leaves the controllers to largely worry just about HTTP – handling requests and composing responses – invoking methods of the model as necessary.