83 lines
4.5 KiB
Markdown
83 lines
4.5 KiB
Markdown
# What is an Application Core?
|
|
|
|
The *application core* (or application) handles all processes that trigger specific functionalities and mechanics of the
|
|
software, like showing the products page, registering a customer account, or placing an order. Because this software is
|
|
a web-based application, the triggers are HTTP requests that will be interpreted and processed by internal components of
|
|
the application. The following picture shows you the essential parts of the *application core*:
|
|
|
|
```
|
|
+----------------------------------------------------------+
|
|
| Application / IoC Container |
|
|
| |
|
|
| +-------------------------+ +-----------------------+ |
|
|
| | Modules | | | |
|
|
| | +-------------------+ | | Domains | |
|
|
| | | Routes | | | | |
|
|
| | +-------------------+ | | | |
|
|
| +-------------------------+ +-----------------------+ |
|
|
| +----------------------------------------------------+ |
|
|
| | Framework / Core Components | |
|
|
| +----------------------------------------------------+ |
|
|
| +--------------+ +-----------------+ +-------------+ |
|
|
| | Kernel | | | | | |
|
|
| | +--------+ | | bootstrappers | | Service | |
|
|
| | | Slim | | | | | Providers | |
|
|
| | +--------+ | | | | | |
|
|
| +--------------+ +-----------------+ +-------------+ |
|
|
+----------------------------------------------------------+
|
|
```
|
|
|
|
# Kernel
|
|
|
|
The *kernel* is the central component that delegates the start, execution, and finalisation of the application. In the
|
|
starting process, it uses *bootstrappers* to set up the application and delegates to specific application services to
|
|
handle incoming requests.
|
|
|
|
The `HttpKernel` implementation is based on the microframework Slim. For execution, the processing of the HTTP request
|
|
will be forwarded to Slim, which receives the incoming HTTP requests and starts the processing that handles these
|
|
requests.
|
|
|
|
Another example for a general use case for a *kernel* would be a CLI program.
|
|
|
|
# Bootstrapper
|
|
|
|
Besides the *kernel*, we have the *bootstrappers*, which set up the application itself. Each *bootstrapper* prepares a
|
|
part of the application before any HTTP requests will be handled. Typical tasks of these *bootstrappers* are the
|
|
registration of components, handling of HTTP sessions, or registration of routes and middlewares.
|
|
|
|
# Service Providers
|
|
|
|
The application is designed in a way that it acts as a DI Container; that allows an easy way of Inversion of Control and
|
|
Dependency Injection. Having a DI Container means that every component or service class used to handle specific
|
|
functionalities of the application needs to be registered. The container/application will generally arrange the
|
|
instantiation of these components, services and classes by itself. The *service providers* are the parts of the
|
|
application responsible for registering these components and services.
|
|
|
|
# Modules
|
|
|
|
After the application has received an incoming HTTP request and determines which module is responsible, a corresponding
|
|
HTTP controller or action will be executed. These controllers or actions are part of the module. A single module only
|
|
provides a fraction of the complete functionality. Therefore, it uses (and sometimes even contains) a domain.
|
|
|
|
# Domains
|
|
|
|
Domain is a term of the Domain-Driven Design and represents a part of the business logic. While an HTTP controller or
|
|
other components of a module orchestrate processes, the domain contains the inner logic and model of the business
|
|
itself.
|
|
|
|
## Layer Dependencies
|
|
|
|
Each module follows strict dependency rules across its three layers:
|
|
|
|
- **Domain Layer**: Must be completely independent with no dependencies on other layers
|
|
- **Application Layer**: Can depend on Domain and Infrastructure layers
|
|
- **Infrastructure Layer**: Can only depend on itself, isolated from Application and Domain
|
|
|
|
This architecture ensures the Domain remains pure business logic, the Application orchestrates use cases, and
|
|
Infrastructure provides isolated external adapters. See [Application Layers](application-layers.md) for detailed
|
|
dependency rules and examples.
|
|
|
|
# Core Components / Framework
|
|
|
|
The *core components* can be used by different *modules*. Systems for caching, logging, or internalization are examples
|
|
forthese kind of components. They can be seen as the general framework for every module.
|