spring boot fat service refactoring

Question

I have a very fat class which hold the code business logic of my application. The class is using other service and sometimes other service's repositories to get data needed for its actions.

The entities in my application are just POJO.

So lets assume the service is InventoryService and it has 200 methods that we want to split up, and it uses the Product, Tax, Customer entities, would it make more sense to transfer the business logic to the entities themselves to reduce the code on the service level? Or rather add more services such as ProductInventoryService, TaxInventoryService and etc.. and move some of the logic to them?

Any practical examples would be appreciated, the basic design of the app is controller >service >repository where we aim to use Entities between all layers and return DTO to the client from the controller. Thanks

Answer 1

So lets assume the service is InventoryService and it has 200 methods that we want to split up, and it uses the Product, Tax, Customer entities, would it make more sense to transfer the business logic to the entities themselves to reduce the code on the service level? Or rather add more services such as ProductInventoryService, TaxInventoryService and etc.. and move some of the logic to them?

You already answer to your own question here. Following the SOLID Principles and spliting your project into Layers, you make your code more clear, readeable and finally more maintainable.

It is very important to have a seperation of concerns in your projects and avoid strong dependencies between your layers or your components.

• By seperating your classes into xxxService, xxxController and xxxRepository, you implement the Single responsability principle.
• By organizing your classes into different layers, you adopt the N-Tiers pattern (at your project and package level)

I would suggest you to post this question in the Software Engineering network.