What do you trade by mapping a transfer model onto a domain object with name-based copying instead of explicit code?

Once a request has been bound into a transfer model, something has to move those values onto the domain object. The mechanism is a real design choice, and it is usually made by habit rather than on the merits. ## The three styles 1. **Explicit mapping.** Code you wrote assigns each value: read a field from the transfer model, transform it if needed, set or pass it on the domain object. Verbose, dull, and completely readable. 2. **Build-time generation.** You declare a pairing between two types and a tool emits the assignment code before the program runs. Almost as terse as reflection, but the emitted code is ordinary code, so mismatches are build failures. 3. **Runtime name matching.** A general-purpose helper inspects both objects and copies every property whose name and type line up. The shortest to write and the loosest. ## The axis that decides it: when a mismatch surfaces | Style | A renamed field shows up | An added field shows up | Type mismatch shows up | |---|---|---|---| | Explicit | immediately, the code no longer compiles or a test fails | when you write the assignment, deliberately | at compile or test time | | Build-time generated | at build time, as an unmapped-property error or warning | at build time, if unmapped properties are treated as errors | at build time | | Runtime name matching | never — the field is quietly skipped | never — it is quietly copied or quietly skipped | at runtime, if at all | The failure mode of runtime matching is the nasty one because it is **silent and partial**. The request succeeds, the response looks right, and one field holds a stale or default value. That defect surfaces days later as a data question, not as an error, and it is expensive to trace back to a rename nobody connected to it. ## The second axis: how much gets copied A hand-written mapping copies exactly the fields you listed. A copy-everything helper copies everything that matches — and that is the same reach problem that made direct binding dangerous in the first place: - If the source is a transfer model and the target is a domain object, a blanket copy will happily overwrite **server-controlled fields** that happen to share a name, such as an identity, an owner, a timestamp or a version. - If the model is later extended with a field meant for a different purpose, the blanket copy starts writing it with no code change anywhere. - Nulls are a trap: an absent field in a partial update becomes a null on the source, and a copy-everything helper cheerfully writes that null over a good value. So the mapping step is not clerical. It is the second half of the boundary — binding decides what a client may *say*, mapping decides what that saying is allowed to *change*. ## Practical guidance - **Prefer explicit or generated mapping on the write path.** This is where a silently skipped or silently copied field has consequences, and where the code is the only record of which values a request may change. - **Be more relaxed on the read path.** Projecting a domain object into a response model is lower risk on the write axis, though a blanket copy there has its own hazard: a newly added internal field can start appearing in responses. - **Never copy blindly into an object whose field set is larger than the source's.** That direction is where privileged fields live. - **Put the mapping in one place per resource.** Scattered ad-hoc copying loses the property that makes explicit mapping valuable — being able to read, in one file, everything a request can change. - **Treat unmapped properties as errors** wherever your generation step can be configured to do so. That single setting converts the silent class of bug into a build failure. - **Test the mapping directly** with a fully-populated source, asserting every target field. It is the cheapest test that catches a rename. ## Why the argument keeps recurring The pull toward automatic copying is real: mapping code is repetitive, it grows with every model, and it feels like ceremony that adds nothing. The counter-argument is not that the code is valuable in itself — it is that the **explicitness** is. The mapping layer is where a human last had the chance to say "this incoming value may become that stored value". Delete that moment and the answer to "what can a client change?" becomes "whatever two type shapes currently have in common", which is a question nobody can answer during a review and which changes every time someone adds a field.