"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.
"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.