What does the Assembler component do in the DTO/Assembler pattern, and where should the mapping logic between a domain object and its DTO live — on the domain object, in the controller, or in a dedicated mapper class?
answer
- toDto/toDomain pair
- keeps domain ignorant of representation
- controller stays thin
- MapStruct = compile-time-checked mapping
- watch for logic creeping into the mapper
basics
~20 sThe Assembler is the piece of code that copies data between a domain object and its DTO, in both directions. It should live in its own small class, not inside the domain object or the web controller, so each side stays focused on its own job.
solid answer
~40 sThe Assembler (or mapper) is a dedicated component whose only responsibility is translating between the rich domain/persistence model and the flat DTO shape: reading fields off the domain object to build a DTO for output, and reading fields off an incoming DTO to construct or update a domain object for input. It should not live on the domain object itself, because that would force the domain model to know about external representation concerns and violate single responsibility. It should not live in the controller either, because that scatters mapping logic across every endpoint and makes it untestable in isolation and unreusable across endpoints that need the same DTO. A dedicated assembler class (hand-written or generated, e.g. via MapStruct) keeps the domain model ignorant of its external representations and keeps the controller thin.
go deeper
Should know the assembler is the thing that converts between a domain object and a DTO and that it's a separate piece of code, without needing to defend the placement decision in depth.
Should explain why the mapping doesn't belong on the domain object or scattered across controllers, using single-responsibility reasoning, and know at least one mapping tool/library by name.
Should discuss the hand-written-vs-generated-mapper trade-off concretely and recognize 'assembler creep' (business logic leaking into the mapper) as a real anti-pattern to guard against in code review.
Should connect the assembler's placement to broader architectural boundaries (hexagonal ports/adapters, layered architecture) and set team-wide conventions for where computed/conditional mapping logic is allowed to live.
## What an assembler does The Assembler is the second half of the DTO pattern and is often under-discussed relative to the DTO itself, but it's where most of the actual engineering judgment lives. Mechanically, an assembler exposes (at minimum) two operations: - one that takes a domain object (or an aggregate, or a JPA entity) and produces a DTO from it — typically called something like `toDto` or `toResponse`; - one that takes an incoming DTO and either constructs a new domain object or applies its fields onto an existing one, typically called `toDomain`, `toEntity`, or `applyTo`. In a typical request flow: 1. a controller receives an incoming request DTO, hands it to the assembler (or to a use-case/service that internally uses the assembler) to become a domain command or entity; 2. the domain layer executes business logic against that; 3. on the way out the resulting domain object is handed back to the assembler to become a response DTO that the controller returns. The assembler is deliberately **dumb**: it copies and reshapes fields, it does not decide business rules, and it does not know about HTTP, transactions, or persistence mechanics. ## Why the domain object is the wrong place for it The reason this needs to be its own thing rather than living inside the domain object is **separation of concerns** in the classic sense: a domain object's job is to enforce invariants and encapsulate business behavior, and it should be usable and testable without any awareness of how it might eventually be serialized to JSON, to a different DTO for a mobile app, or to a message payload for an event bus. If you put a `toDto()` method directly on the domain entity, you've coupled the domain model to one specific external representation, and the moment a second client needs a different shape (a summary DTO with three fields versus a detail DTO with twenty), you either bloat the domain class with multiple `toXyzDto()` methods or you're back to needing an external mapper anyway. ## Why the controller is the wrong place for it Putting the logic in the controller instead has a different but equally real cost: - mapping code gets copy-pasted or subtly reimplemented across every endpoint that touches the same entity; - it can't be unit tested without spinning up the web layer; - it tends to accrete business-adjacent decisions (like which fields to compute or default) into the transport layer, where they don't belong and are easy to miss during review. ## Hand-written versus generated mappers The trade-off in choosing a dedicated assembler is mostly about how the mapping code is authored and maintained. **Hand-written assemblers** are explicit and easy to debug but grow tediously with every new field, and it's easy for a field to silently go unmapped after a domain class changes — a bug that a compiler won't catch if both sides happen to compile independently. **Generated mappers** (MapStruct is the standard example in the Java/Kotlin ecosystem) trade a little magic and a build-time code-generation step for compile-time safety: MapStruct generates real Java source that fails to compile if a target field has no matching source and no explicit mapping rule, catching missing-field bugs at build time instead of in production. The cost there is: - an extra build-time dependency; - a generated-code step that needs to be understood by anyone debugging a mapping issue; - slightly awkward handling of anything that isn't a straightforward one-to-one field copy (computed fields, nested object graphs, conditional logic), which usually needs a hand-written `@AfterMapping` hook. ## Assembler creep, and the fix A concrete failure mode of getting this placement wrong shows up as 'assembler creep': what starts as a clean, single-purpose mapper slowly accumulates business logic because it's the one place that has both the domain object and outgoing shape in hand at once — someone adds 'if the order is cancelled, set the display status to Refunded' directly inside the assembler because it's convenient, and now a business rule lives in the translation layer instead of the domain, invisible to anyone testing the domain model in isolation and duplicated the next time a second assembler needs the same rule for a different DTO. The fix is discipline: the assembler only copies and reshapes already-computed domain state; any decision that changes behavior based on domain rules belongs on the domain object (e.g., an `Order.displayStatus()` method) or in the use-case/application-service layer, and the assembler just calls it. A well-known real-world convention that encodes this separation explicitly is layered architecture guidance (e.g., Spring's common controller-service-repository split, or hexagonal architecture's port/adapter boundary), where the assembler sits squarely at the adapter boundary — translating at the edge, never deciding in the middle.
- What's the practical downside of using a code-generation mapper like MapStruct versus hand-writing the assembler?You add a build-time annotation-processing dependency, and debugging requires looking at generated source you didn't write, which can be an unfamiliar step for newcomers. It also handles simple field-to-field copies very well but gets awkward for computed or conditional fields, usually pushing you toward a hand-written @AfterMapping method anyway.
- Should the same assembler handle both directions (domain-to-DTO and DTO-to-domain), or should those be split?Either is defensible; many teams keep both directions in one mapper class since they're conceptually the same translation and it avoids duplicated field-name knowledge across two files. Splitting makes sense once the two directions diverge significantly in complexity, e.g., the inbound direction needs heavy validation/enrichment while the outbound direction is a trivial flatten.
- If a domain aggregate has fields the DTO should never expose (like an internal risk flag), how does the assembler enforce that?By construction: the assembler only writes the fields it's explicitly told to write into the DTO, so any field not referenced in the mapping method simply never appears in the output. This is the allowlist property of DTOs in action — omission from the mapper is the enforcement mechanism, no separate access-control step is needed.
The assembler is like a court interpreter: they translate faithfully between two parties who speak different languages, but they never argue the case themselves — the moment an interpreter starts inserting their own opinion into testimony, something has gone badly wrong, just like when business logic creeps into a mapping class.
saying these in an interview costs you the question
- Puts toDto()/toEntity() methods directly on the JPA entity or aggregate root
- Writes mapping logic inline inside the controller method for every endpoint
- Doesn't distinguish 'copying a field' from 'deciding a business rule' when describing what belongs in the assembler
- Assumes a mapping library eliminates the need to think about unmapped or renamed fields
- Can't explain why domain objects shouldn't know about their DTO representations