chore: Refactor Mandatorymodule controller to 3 tier structure

[ruanxin]

Description

This PR introduces a layered architecture for the mandatory module controller, aiming to improve the maintainability and scalability of the KLM (Kyma Lifecycle Manager) codebase. This serves as an example for team discussions on refining the overall reconciliation logic and guiding future refactoring efforts.

Proposed Architecture

1. Reconciliation Controller Tier

This layer acts as the entry point for the reconciliation process and is responsible for handling all reconcile related logic.

• The controller remains lightweight, focusing on processing reconciliation requests and delegating business logic to the appropriate domain models.
• Business logic does not handle ctrl.Result directly—this ensures clear separation and avoids tight coupling between reconciliation flow and business processing.
• This tier also ensures proper error handling and requeue strategies, abstracting them away from the business logic.

2. Business Logic Tier

The business logic layer is structured based on Domain-Driven Design (DDD) principles.

• Logic is encapsulated within domain models, which categorize different aspects of the system.
• Each Custom Resource Definition (CRD) naturally maps to a domain model, but we avoid fat domain models by further specializing models where appropriate.
  • Example: The module concept does not have a dedicated CRD, so we introduce distinct models such as Regular Module and Mandatory Module.
  • Instead of designing monolithic domain models with excessive behavior, we ensure that dependencies are structured properly to avoid creating a domain service with all dependencies.
• This approach ensures better modularity and reusability, preventing bloated domain models while maintaining clear separation of concerns.

3. Data Tier

The data tier is strictly responsible for data access and persistence, ensuring domain models remain independent of direct API interactions.

• All interactions with the API Server are encapsulated within repositories, which are designed specifically for each CRD.
• This ensures domain models do not handle data access logic directly, reinforcing the principles of clean architecture.

Key Benefits of This Approach

Maintainability – Changes in one layer do not impact others directly.
Scalability – Easier to introduce new features and extend domain logic.
Testability – Each tier can be tested independently, improving reliability.
Clarity & Separation of Concerns – Avoids tightly coupled logic between reconciliation, business rules, and data access.