Let's separate the separation

Published: (December 31, 2025 at 03:30 PM EST)
2 min read
Source: Dev.to

Source: Dev.to

Introduction

During the last days of 2025, our team lead took an extra day off and missed an important meeting. After a recent restructure, one colleague left the project and two newcomers joined. The discussion focused on how to structure the new code for a Spring Boot web project.

Current Approach

For the past ~10 years of my professional career, the most common pattern has been:

  1. DTO POJOs at the entrance/exit of the REST controllers.
  2. Entity objects that map directly to the storage schema (e.g., a relational database).

Occasionally, process‑exclusive POJOs exist, but they are omitted here for simplicity. The workflow looks like this:

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper
   ↔ Entity (persistence)

Separating request/response objects from storage entities allows for different structures and future‑proofs the code against changes.

However, this does not fully decouple the core logic from the repository layer: any change to an entity directly impacts the core. In practice, entities are rarely altered without a corresponding business‑logic need, so I have habitually used only DTOs and entities.

Decision to Fully Decouple

Despite my reservations, the team decided to fully separate the core from the repository. The new layout introduces additional mapper classes and POJOs that duplicate the entities:

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper (DTO ↔ Domain Model)
   ↔ Domain Model (core)
   ↔ Mapper (Domain Model ↔ Entity)
   ↔ Entity (persistence)

Concerns

  • Increased complexity: More classes mean more places to modify when requirements change.
  • Maintenance overhead: Over time, the extra layers can become a source of unnecessary complication.

On the other hand, this separation could be beneficial if the core’s internal structure diverges significantly from the repository’s schema, allowing each layer to evolve independently.

Conclusion

I’m open to constructive feedback and willing to adjust if the added abstraction proves valuable.

Happy holidays to everyone!

Back to Blog

Related posts

Read more »