ATTENTION: You are on the develop branch.
This has been renamed to master.
The develop branch will not be maintained anymore.
It is only left here to avoid broken links to existing content.
Please update links to point to the master branch.
For details look at issue #320.
Following separation-of-concerns we divide an application into components using our package-conventions and architecture-mapping. As described by the architecture each component is divided into these layers:
-
client-layer with the dialogs to view and modify the component’s data.
-
service-layer with the services to access the component’s data remotely.
-
logic-layer with the component-facade providing the business-logic to manage the component’s data.
-
dataaccess-layer with the entities defining and the repositories (or DAOs) accessing the component’s data.
Please note that only CRUD oriented components will have all four layers within the same component. Some types of applications may have completely different components for the client.
Cross-cutting aspects belong to the implicit component general. It contains technical configurations and very general code that is not business specific. Such code shall not have any dependencies to other components and therefore business related code.
The business-architecture defines the business components with their allowed dependencies. A small application (microservice) may just have one component and no dependencies making it simple while the same architecture can scale up to large and complex applications (from bigger microservice up to modulith).
Tailoring an business domain into applications and applications into components is a tricky task that needs the skills of an experienced architect.
Also, the tailoring should follow the business and not split by technical reasons or only by size.
Size is only an indicator but not a driver of tailoring.
Whatever hypes like microservices are telling you, never get misled in this regard:
If your system grows and reaches MAX+1 lines of code, it is not the right motivation to split it into two microservices of ~MAX/2 lines of code - such approaches will waste huge amounts of money and lead to chaos.
Only in case you need cross-cutting code that aggregates another component you may introduce the component app.
It is allowed to depend on all other components but no other component may depend on it.
With the modularity and flexibility of spring you typically do not need this.
However, when you need to have a class that registers all services or component-facades using direct code dependencies, you can introduce this component.
The following class diagram illustrates an example of the business component Staffmanagement:
In this scheme, you can see the structure and flow from the service-layer (REST service call) via the logic-layer to the dataaccess-layer (and back).