:broom: Eliminating mapper boilerplate in Kotlin ...
# feed
l
🧹 Eliminating mapper boilerplate in Kotlin 😩 Every layer your domain model touches — HTTP, persistence, another service's contract — tends to get its own near-identical data class, plus a pair of mapper functions to translate between them. That is boilerplate that grows with every layer, and business logic that slowly leaks into mapper code instead of staying on the model. ✨ Kotools Facet is exploring a domain-first alternative: declare projections on the model itself, and let the compiler generate the mapper you'd otherwise write by hand. 🔗 Full writeup: github.com/kotools/facet/discussions/4
kodee loving 1
s
l
@Sebastian Schuberth Thanks for the links! These tools (Mappy, KConMapper, KDataMapper, KMapper) all generate the mapping function between two classes that already exist (e.g. DTO → Entity). They remove the mapper, not the duplicated classes. Kotools Facet goes further: a single domain model, projected directly into layers via a DSL (
hide()
,
map()
,
rename()
) — no `UserDto`/`UserEntity` to maintain at all.
💡 1
s
Maybe that's worth to mention in the
README.md
, in some kind of "Similar Tools" / "Comparison" section?
👍 1
l
@Sebastian Schuberth Thanks for suggesting this! I was editing the README according to your question: the new section is now live. 🙂
🙏🏻 1