Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.
Isn't that a textbook example of object oriented programming? Whether OOP is a mistake in and of itself is another question ...
Dog dog = new Dog("Spot");
dog.bark();
And if you say in a bloody "service", which just has the object passed as the first variable into every bloody method, I swear I'll come down there and strangle you with your own keyboard cord.
That's the actual textbook definition of tight coupling.
I'm working on a project which has 5 layers, business objects with no methods, a dto layer, a dal layer, a service layer and finally the website. All incredibly tightly coupled and utterly pointless.
It's an utter nightmare. Every time I touch the code half of it disappears, right now I've still deleted more lines than I've added while adding a ton of functionality.
That idea is so broken because it violates KISS, YAGNI and DRY all in one in a futile attempt to "decouple" things which are obviously coupled because the data is needed to perform the business rules.
There's a malaise in modern programming and it's the dogmatic pursuit of decoupling over simple and clear code.
It's not always appropriate, but building some language-idiomatic encapsulation around data from the very start makes it much less likely that the inevitable addition of hundreds or thousands of lines of logic will descend into incomprehensible spaghetti hell. This doesn't have to be OOP; it could just as easily be e.g. a module in a purely functional language.
Then why do you have it at all?