Comment by elric
4 days ago
Why did you create an anemic domain model?
Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient.
record User(String name){}
Records are great when doing more "data oriented programming".
I don't think anyone sets out to make an anemic domain model, it just happens. Lots of developers start with POJO's for JPA models and then never advance them into being full fledged objects when the requirements develop.
Surely that's a conscious design decision? Deciding to create data-carrying POJOs with JPA annotations is a valid strategy. Mixing in a bunch of logic and non-JPA state with them is a recipe for disaster. If you want your classes to Do Stuff, you have to design them to Do Stuff.
I dislike the term "anemic domain model", it casts a value judgment which I think is unwarranted. There's a spectrum from anemic to obese (for want of a better word). There are tradeoffs all along that spectrum. Finding a sweet spot will depend heavily on what you're doing, why you're doing it, what your team is comfortable with etc.
I genuinely believe its not a conscious design decision. Most people never properly learn how to turn things into objects. I've seen this happen in many projects across many companies. They simply just write procedural code without centralizing their logic anywhere.
That's not object oriented though
Does it have to be? Java is a hybrid paradigm language. It's perfectly fine to write data-oriented code. And if you're using an anemic model, there's no point paying the overhead price of fully fledged classes.
I meant, if you want to evaluate OOP by itself, you can't use things that break the paradigm. Java broke that probably because they realized OOP isn't always a good idea, after sticking to it up through v7.