Clean Architecture: DTOs Are NOT Just Wrappers

Code Example

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

---

Developers like DTOs. And wrappers. And more wrappers.

Until your “simple” API layer turns into a tower of classes no one can read, tests become painful, and adding a new field feels like a chore.

DTOs and mappers are tools — not dogma. Clean Architecture doesn’t say “wrap everything 5 times.” It says: be intentional about what crosses boundaries.

The Problem

Many codebases follow a pattern like this:

Domain objects
   ↓
Domain DTO
   ↓
Application DTO
   ↓
API DTO
   ↓
JSON

That’s 3–4 layers of wrapping for the same data, plus mappers everywhere.

To be clear — sometimes multiple layers are justified. If you're serving both GraphQL and REST from the same domain, or maintaining a published API contract that must change independently from your domain, extra DTOs earn their keep. The problem isn't layers — it's layers that exist "just in case."

The result:

• Lots of boilerplate

• Hard to understand what actually changes the domain

• Fragile tests because every layer must be mocked

• Accidental complexity: devs can’t tell which layer matters for business rules

---

🚀 Register now: Acceptance Testing Workshop
Get 100 EUR off with code EARLYBIRD100

---

💡Code Example

Over-Wrapping Everything ❌