:toc: macro
toc::[]

= Components

Following link:architecture#architecture-principles[separation-of-concerns] we divide an application into components using our link:coding-conventions#packages[package-conventions] and link:guide-structure[project structure].
As described by the link:architecture[architecture] each component is divided into layers as described in the link:guide-structure[project structure].
Please note that a component will only have the required layers.
So a component may have any number from one to all layers.

== General Component
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.

== Business Component
The link:architecture#business-architecture[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.

== App Component
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.

== Component Example
The following class diagram illustrates an example of the business component `Staffmanagement`:

image::images/guide-logic-layer.png["logic layer component pattern",scaledwidth="80%",align="center"]

In this scheme, you can see the structure and flow from the link:guide-service-layer[service-layer] (REST service call) via the link:guide-logic-layer[logic-layer] to the link:guide-dataaccess-layer[dataaccess-layer] (and back).