[FIXED] Spring - Package structure - [.../compontent/layer] vs [.../layer/component]

Issue

We currently have a larger Spring project, which consists of different project components. Unfortunately, the packaging is currently relatively unfavorable, which is why I want to refactor the whole thing.

Our basic framework uses package by layer, which is why I - at least for the time being - would like to stick with it in our project. I would like to ask you which kind you consider more useful:

variant 1:

- src/main/java
     - com/company/core
       - dao
         - CoreThing1Repository
         - CoreThing2Repository
       - domain
         - CoreThing1
         - CoreThing2
       - dto
       - service
         - CoreThing1Service
         - CoreThing2Service
     - com/company/component1
       - dao
         - Thing1Repository
         - Thing2Repository
       - domain
         - Thing1
         - Thing2
       - dto
       - service
         - Thing1Service
         - Thing2Service
     - com/company/component2
       - dao
         - Thing3Repository
         - Thing4Repository
       - domain
         - Thing3
         - Thing4
       - dto
       - service
         - Thing3Service
         - Thing4Service
     - com/company/component3
       - dao
         - Thing5Repository
         - Thing6Repository
       - domain
         - Thing5
         - Thing6
       - dto
       - service
         - Thing5Service
         - Thing6Service

variant 2:

- src/main/java
     - com/company/dao
       - core
         - CoreThing1Repository
         - CoreThing2Repository
       - component1
         - Thing1Repository
         - Thing2Repository
       - component2
         - Thing3Repository
         - Thing4Repository
       - component3
         - Thing5Repository
         - Thing6Repository
     - com/company/domain
       - core
         - CoreThing1
         - CoreThing2
       - component1
         - Thing1
         - Thing2
       - component2
         - Thing3
         - Thing4
       - component3
         - Thing5
         - Thing6
     - com/company/dto
       - core
         - CoreThing1Repository
         - CoreThing2Repository
       - component1
         - Thing1Repository
         - Thing2Repository
       - component2
         - Thing3Repository
         - Thing4Repository
       - component3
         - Thing5Repository
         - Thing6Repository
     - com/company/service
       - core
         - CoreThing1Service
         - CoreThing2Service
       - component1
         - Thing1Service
         - Thing2Service
       - component2
         - Thing3Service
         - Thing4Service
       - component3
         - Thing5Service
         - Thing6Service

In terms of content, I like variant 1 very much, because the components come out better - but the whole thing is neither package by feature nor package by layer? Should you even do such a mix?

Which variant would you choose or which varainte do you use in your environment?

Solution

I like variant 1 very much. The reason is that you can have finer control over the visibility of your class methods.

A good example is the DAO class. Usually, you don't want the DAO class to be accessed by other Services than the one about the same business logic (in your case regarding the same component). You can't do this if you are using variant 2, because all methods must be public so that the corresponding Service is able to call the DAO class. But you can actually do this in Java by using no modifier or protected modifier. This will make your code more readable and better organized. Additionally, it would be easier to add or remove components, because all its logic is inside the same package.

Answered By - João Dias