Following separation-of-concerns we divide an application into components using our package-conventions and project structure. As described by the architecture each component is divided into layers as described in the 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.
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
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.