0
I’m part of a Spring Boot development team and the project is getting bigger and bigger. Our problem is that even separating methods according to their related entity, the service classes become very extensive.
Our team separates the project into the following packages:
- Configuration - Database and data format configuration classes.
- Controller - Classes that provide services that external Apis may use.
- Entity - Entities representing tables in the database. There is also a package of Dtos for specific inputs and outputs.
- Integration - Classes used to call services from other Apis.
- Model - Model classes to use as encapsulation of the returns of external Apis.
- Repository - Classes that connect to the database.
- Service - Classes containing the business rules and calculations needed to complete the service the controller requested.
- Exception - Classes of auxiliary exceptions.
The problem arises when, for example, the class ClienteService have many private methods, in addition to the public that will be called by a ClienteController.
I wonder if there is any way to organize the code, and the business rules, more correctly and that would facilitate maintenance for developers in the future.
You can opt for a change in architecture, take a look at Clean Architecture. A good example of modularized design: [1] https://github.com/helpdeveloper/java-modular-architecture [2] https://github.com/AndreyGFranca/customers
– Andrey França
Problem facing is architectural, if the application is a monolith, can try the modular monolith strategy or risk a little more and go to Microservices
– Renan
In my poor understanding the business rules should stay on the Model layer, which represents the domain model, and Service would be application layer (application rules), which has a question here at Sopt explaining what it does.
– Piovezan