No escaping on dozens of mappers?

[RangelReale]

Question or proposal

Looks like for safe and correct DDD, we can't escape from dozens of mappers, which means adding a new field in some entities requires changes to 6+ files.

I get that the end product is much better and much easier to maintain, but this is always a pain.

Context

No response

[sklinkert]

You're right, and I won't pretend otherwise: adding a field to Product touches the entity, the command, the result, the request DTO, the response DTO, the mapper, and the SQL query. That's the actual price of the architecture, and anyone who tells you it's free is selling something.

Why I still pay it: each of those files is a boundary that can change independently. The wire format can stay stable while the domain renames things (just went through exactly that with the minor-units rename in #89 - the API could have kept its old shape if I'd wanted). The moment you collapse them into one struct, every refactoring becomes a breaking API change and every json tag becomes domain design.

That said, three things keep the cost bearable in practice:

1. The changes are mechanical. Six files, but zero thinking - each mapping is a dumb field copy, the compiler tells you every place you missed, and there's no action at a distance. I'd rather have 10 boring minutes than 1 clever indirection.
2. sqlc generates one of the layers for free, and if the mapping burden grows, mapper generation is a legitimate next step (goverter, or go generate with templates). Generated boredom is the best kind.
3. Not every field needs all layers. A purely internal field stops at the entity and the DB. Only fields that cross the API boundary pay the full toll.

[RangelReale]

Would you think of using a code generator like "goverter" to generate the mappers? It seems that case where the easy parts are easy, but the moment you have a mapping which isn't exactly one-to-one, then it becomes much harder.

[sklinkert]

I've considered it, and for this template the answer is no, for the reason you already named: the moment a mapping isn't 1:1, generators make it harder, not easier.

Look at which mappings here are actually non-trivial: reading a row back routes through NewMoney so a corrupt currency fails at the boundary, and Money explodes into two primitives (price_minor_units + currency) on the way out. That's precisely the part goverter needs custom extend functions for - so you end up writing the interesting mapping code by hand anyway, plus maintaining the generator config, plus a build step. Two systems where one was enough. The dumb 1:1 copies that goverter automates well are the ones that were never the problem.

There's also a teaching-template reason: the explicit mappers are load-bearing content here. They're where you can see the validation routing happen. Generated code would hide the one thing the repo exists to show.

[RangelReale]

One big problem I often see is someone forgetting to update one of the mappers, and this is a silent failure, it won't show up anywhere (except if you have tests check every single field of every entity). I tried to think of something to validate this in CI, but there isn't anything that catches this.