Springboot Package by Feature Vs Package by Layer
Package by Feature: Sample say a product Feature will contain all the stuff related to products i.e Domain, controller, service, models, repository, configuration.
Well structured code takes longer to set up, but will pay huge dividends later:
Model. Where the definitions of objects you persist to storage, so table or node definitions
Repository, the interfaces that you call to read or write persisted data(Data access abstraction)
Controller. The classes and methods called by a rest or graphql based front end(Handle http Request and Responses)
Service. The business logic. Called by the controller, using repositories to access data models
You can extend this to add layers to isolate what the front end accesses from the models:
DTO. Data transformation objects, these are classes that the front end uses: Mostly is a plain old Java object, used to pass data between layers (http <> controller, controller <> service)
An entity refers to a class that represents a table in a database. Entities are annotated with @Entity (e.g., JPA's @Entity annotation) and are used to map database tables to Java classes. They are used in the data access layer of an application.
NOTE: Modern Java (Spring): In modern Spring Data JPA applications, the framework's @Repository interface effectively acts as both a repository and a DAO, combining the high-level interface with automatic, low-level data access implementations.
For typical business applications, the package-by-feature style seems to be the superior of the two:
Higher Modularity
As mentioned above, only package-by-feature has packages with high cohesion, high modularity, and low coupling between packages.
Easier Code Navigation
Maintenance programmers need to do a lot less searching for items, since all items needed for a given task are usually in the same directory. Some tools that encourage package-by-layer use package naming conventions to ease the problem of tedious code navigation. However, package-by-feature transcends the need for such conventions in the first place, by greatly reducing the need to navigate between directories.
Higher Level of Abstraction
Staying at a high level of abstraction is one of programming's guiding principles of lasting value. It makes it easier to think about a problem, and emphasizes fundamental services over implementation details. As a direct benefit of being at a high level of abstraction, the application becomes more self-documenting: the overall size of the application is communicated by the number of packages, and the basic features are communicated by the package names. The fundamental flaw with package-by-layer style, on the other hand, is that it puts implementation details ahead of high level abstractions - which is backwards.
Separates Both Features and Layers
The package-by-feature style still honors the idea of separating layers, but that separation is implemented using separate classes. The package-by-layer style, on the other hand, implements that separation using both separate classes and separate packages, which doesn't seem necessary or desirable.
Minimizes Scope
Minimizing scope is another guiding principle of lasting value. Here, package-by-feature allows some classes to decrease their scope from public to package-private. This is a significant change, and will help to minimize ripple effects. The package-by-layer style, on the other hand, effectively abandons package-private scope, and forces you to implement nearly all items as public. This is a fundamental flaw, since it doesn't allow you to minimize ripple effects by keeping secrets.
Better Growth Style
In the package-by-feature style, the number of classes within each package remains limited to the items related to a specific feature. If a package becomes too large, it may be refactored in a natural way into two or more packages. The package-by-layer style, on the other hand, is monolithic. As an application grows in size, the number of packages remains roughly the same, while the number of classes in each package will increase without bound.