Is it correct to use Lombok in a domain object?

Question

I'm starting the refactoring of a legacy app in favor of having a more organized structure, I chose to go with hexagonal architecture since I have lots of well-defined ports and adapters, my use cases are clear as well as the domain. One of the things I found in this legacy is the usage of lombok almost everywhere, when the theory clearly states that the domain models should remain clean from external dependencies (pure java code that can be moved everywhere), and this enters into a small contradiction with what it's done. My question is, is it correct to use Lombok in my domain objects or should I fully scaffold the class, I do read-only classes so getters is the only thing I put there but still looks verbose.

Thank you for the answer in advanced.

Answer 1

Lombok is reflecting that Java is limited in it's ability to model a domain and the reality of systems where there is data and there is code. Separate.

Oracle is delivering "records" in JDK 16 (https://openjdk.java.net/projects/jdk/16/, https://openjdk.java.net/jeps/395) which reflects, I think, that Lombok is serving a need. JEP-395 (records) provides what Lombok does, e.g. record Point(int x, int y) { } has getters, hashCode, equals, toString. All in 1 line. A huge improvement. Better than Lombok because it's built into the language and is therefore portable.

Java is weak at domain modelling. Perhaps you have the freedom to mix in some Kotlin? Kotlin has records in the language, solves the null/optional issue, choice types, etc.

Perhaps it's worth reflecting upon if OOP is giving you much apart from comfort? After 20 odd years doing OOP (C++ and Java) I'm now rapidly going off it in favour of Kotlin and a much more functional approach; I think OOP is not fit-for-purpose. A side-project has been rewritten in functional Kotlin and I'm finding very little use for classes.