…in fact they probably should. I was recently told that logic shouldn’t be put into the domain because the domain objects are simple POCO’s. This seems to be a misunderstanding of the term.
POCO is derived from the term POJO, first defined by Martin Fowler et al. A POJO (Plain Old Java Object) is simply an object that has no dependency on an external framework, a backlash to EJB’s and heavy fraweworks that enforced inheritance.
POCO’s, like POJOs never precluded behaviour. In fact, POCO’s without behaviour are commonly referred to as “Anemic”, an anti pattern described by Fowler here.
In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you’ve robbed yourself blind.
This doesn’t mean Anemic Models are all bad, as Jimmy Bogard writes here: “Context is King” and sometimes a “Persistent Model” is sufficient to meet the systems needs.
So when thinking about modeling your domain, don’t simply disregard modeling it’s behaviour because they are only “simple POCO’s”, you might be robbing yourself blind.
Some people can’t decouple behaviour from persistence; therefore they only think in terms of service-type classes being able to “do” stuff. This is not true; classes in your object model often need to “do” stuff that isnt necessarily related to how their state is managed.
The OO 101-canonical “Car” example is a good one.