The project architecture is organized around the following logic:

• flow - Controllers (routers) decide which services are used to handle business logic.
• business - Interactors utilize services to manage business logic.
• domain - Autonomous services are responsible for specific functions or processes.
• data - Data access is exclusively managed by services.

Key Features:

1. Clear Division of Responsibilities

Each service is responsible for a single, clearly defined functional area, such as:

• User management
• Authorization
• Order processing

2. Service Autonomy

Services are independent and act as separate autonomous units that collaborate to handle business logic.

3. Reusability

A service can be reused across different interactors. For example, the payment service can handle multiple domains, such as subscriptions and the store.

4. Scalability

Services can be scaled independently. For instance, if the order processing service requires more computational power, it can be scaled without affecting other parts of the system.

5. Development Flexibility

Each service can be developed independently, allowing parallel development and faster implementation of changes.

6. Simplified Maintenance and Upgrades

A service, as an isolated unit, is easier to test, update, and refactor.

7. Separation from the Transport Layer

Interactors are independent units and are not tightly coupled to the HTTP API. Processes can be easily switched to background tasks or other methods.

Project Responsibility Structure

Below is the project structure with explanations for the chosen design solutions.

Routers

Routers handle the HTTP transport layer, acting as controllers. Their responsibilities include:

• Validating data
• Preparing data for further processing
• Creating responses
• Serializing data correctly

We avoid implementing business logic directly in routers. Instead, interactors are designed to handle such logic.

Interactors

Interactors are classes that directly manage business logic. They use services to process requests. Each service in an interactor should be publicly registered so that, in certain cases, the interactor can act as a facade. Learn more: Facade Pattern.

Services

A service is an abstraction that encapsulates a specific domain into an autonomous unit. Within its domain, all functionalities are handled by the service. Services can directly use repositories for data access. They act as facades, with all attributes being private.

Repositories

Repositories manage data access and allow modifications to how data is stored or retrieved without affecting the details. This design enables future optimizations, such as caching or improving search functionality. This layer ensures the system's ability to evolve independently of the chosen data storage and manipulation methods.