[Spearchucker]

First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world.

Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data.

So guilt because anemic strikes me as... odd. Modern connected apps aren't written as single-tier Smalltalk apps.

[lonelappde]

You wouldn't send a business rule from a web page, you'd put it in the domain model on the server.

The web page has a UI model, not a domain model.

[Spearchucker]

That's the point. And yet Fowler objects because it violates encapsulation and information hiding, because it requires a service layer and makes a model less expressive.

[extra_rice]

You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the view layer in this particular example need to know the encapsulated business rule? In my experience, not usually. Otherwise, there's most likely a problem with responsibilities. And when that data comes back from the UI, it's also relatively easy to reconstitute it back to well fleshed out objects.

[Spearchucker]

This I know. The point isn't how one might do it, or whether it can be done¹. The point is that Fowler has issues with anemic objects, even though there are patterns in distrubuted computing best solved by anemic objects.

¹ Note that reconstitution does not do away with anemic objects - reconstitution does not implement logic in a purely object-oriented way, i.e. the logic does not travel, but the data does.