The recommended Spring Boot project structure leads to repetitive code

Question

When implementing projects in Spring Boot (especially CRUD applications), I often find myself writing a lot of repetitive code that just calls functions and services from lower layers. For example, when implementing a web service with some REST API, you end up with a controller, a service, a repository, and a model for each feature. This is the recommended structure of Spring Boot projects. In most cases, the model is specific to the feature. The repository then implements basic methods to access and modify the data (for example, CrudRepository), together with some custom queries. The service calls the functions of the repository and adds some custom logic on top. However, it is often the case that the service mimics the functionality of the repository (get, search, list, ...). The controller is again quite similar to the service. It might handle the parsing of the parameters and could be used to enforce access control. Then, it forwards the call to the underlying service. So, custom logic is implemented in the service and (to some extent) in the repository. But in CRUD applications, often there is not a lot of custom logic, and in these cases, I find repetitive code bothersome. Especially when changing something in the model, as this requires adjusting the code in all four layers.

Now, my question. Is this a common problem? Can I circumvent it somehow? Would Spring Data REST go in the right direction? Are there code generators that can help?

Answer 1

The "recommended structure" chooses a weak example, specifically it appears to show an application exposing a set of DB tables as REST services. If that's all you wanted to do there are no code solutions which expose databases via REST.

DDD

A different starting point would be DDD (Domain Driven Design) the idea there is that you choose an application level domain model that corresponds to the real world domain that you are implementing (thats a very brief summary - Eric Evans wrote a whole book on what DDD is).

If you follow this design the repository/serialization layer becomes a way to efficiently load/store the domain model to the database. The API/Controller tier provides actions that can be performed on the domain - rather than just handing the whole object to the client let them manipulate it and give it back to you, so that you can serialize it back to the DB.

Are there code generators that can help?

You may want to look into OpenAPI - you can use that to define/document your public API, typically it generates the entry points (Controllers in Spring Boot) and API DTOs - the objects that are serialized over the network. Note: I use Kotlin which is helpful, because I can use "extension functions" to add additional functionality to generated code - I don't think Java has a similar concept yet, so code generation may be less useful to you.

CQRS

An alternate starting point may be to take a look a the types of queries that you currently have, that return large amounts of data.

These may make good candidates for new transfer models i.e. a model that contains specific fields needed by the front end grouped logically so that the front end only has to make a single call. This is the Q (Query) part of the CQRS design.

TBH - Their usually isn't much logic in query implementations the most complex thing they do is run slightly more complicated SQL statements to avoid the N+1 problem. Other than that they are generally just loops converting from the Database DTO's to the API DTO's.

Combination

You can combine both techniques together. When updating the model you have a real (DDD) model with true actions that can be performed.

And you have a set of lightweight query API's, so that you don't have to load the whole domain model each time.