However, I disagree with how you interpret what Fowler means by "anemic". Yes, if your methods are affecting other application states, that's poor encapsulation; or, if your domain model is holding onto database connections, that's probably not the right place for it. But that's not what he's talking about.
A domain model is anemic when it isn't owning the business logic that it rightfully should own. (i.e...."Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming.")
In my example, the ActivityFilter ought to own the business logic around what the correct activity date is.
I don't make IsActivityDateSetToToday an exposed method because that's exactly the opposite of what I want to achieve. It's an internalized parameter that only the ActivityFilter knows about so that it can deduce what ActivityDate to hand back to whomever asks for it.
"In my example, the ActivityFilter ought to own the business logic around what the correct activity date is."
Perhaps I've misread the article, but I don't think this is the case. The ActivityFilter knows what date the user chose, but if that needs to be changed dependent on some outside conditions it shouldn't own that behavior. I think you should keep ActivityFilter as it is originally described.
You should have another class, perhaps FilterDateService that has a method like GetFilterDate(ActivityFilter) DateTime or something like that that handles that business logic of retrieving the actual date you want to use.
I think we're basically just having the very debate that Fowler is having between those that view anemic domain models as an anti-pattern and those that do this by design to adhere to another kind of architecture (aka a service-oriented).
From his post: "Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data."
I'd argue against the service-oriented approach for this specific case because it feels like a lot more hoops to jump across to get the right date. Why not just grab ActivityFilter.ActivityDate as opposed to instantiating a new service and calling a method against it?
I'm not against a service approach at all (I do it alot) but I think certain logic (my example being one) is better served inside a domain model, even if the models all get tossed around between services.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Nate -
Yes, I know you can add methods to domain models.
However, I disagree with how you interpret what Fowler means by "anemic". Yes, if your methods are affecting other application states, that's poor encapsulation; or, if your domain model is holding onto database connections, that's probably not the right place for it. But that's not what he's talking about.
A domain model is anemic when it isn't owning the business logic that it rightfully should own. (i.e...."Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming.")
In my example, the
ActivityFilterought to own the business logic around what the correct activity date is.I don't make
IsActivityDateSetToTodayan exposed method because that's exactly the opposite of what I want to achieve. It's an internalized parameter that only theActivityFilterknows about so that it can deduce whatActivityDateto hand back to whomever asks for it."In my example, the ActivityFilter ought to own the business logic around what the correct activity date is."
Perhaps I've misread the article, but I don't think this is the case. The ActivityFilter knows what date the user chose, but if that needs to be changed dependent on some outside conditions it shouldn't own that behavior. I think you should keep ActivityFilter as it is originally described.
You should have another class, perhaps
FilterDateServicethat has a method likeGetFilterDate(ActivityFilter) DateTimeor something like that that handles that business logic of retrieving the actual date you want to use.I think we're basically just having the very debate that Fowler is having between those that view anemic domain models as an anti-pattern and those that do this by design to adhere to another kind of architecture (aka a service-oriented).
From his post: "Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data."
I'd argue against the service-oriented approach for this specific case because it feels like a lot more hoops to jump across to get the right date. Why not just grab
ActivityFilter.ActivityDateas opposed to instantiating a new service and calling a method against it?I'm not against a service approach at all (I do it alot) but I think certain logic (my example being one) is better served inside a domain model, even if the models all get tossed around between services.