Design and Implementation of a Multi‑Layered Basic Framework Architecture

Background : As business demands grow, third‑party integrations increase, and new apps are produced rapidly, extending existing code without affecting legacy logic becomes challenging; a well‑designed basic framework is needed to enable fast reuse, reduce mesh coupling, and lower development, testing, and maintenance costs.

Design : The framework is organized through vertical slicing, horizontal slicing, and three‑dimensional expansion. Vertical slicing encapsulates single business or functional modules to avoid cross‑responsibility dependencies. Horizontal slicing creates layered separations for business, functional, and foundational dependencies, allowing integration at different levels. Three‑dimensional expansion facilitates quick app integration and output.

The architecture consists of four layers:

Business Module Layer : Manages interactions among business logic, functional modules, UI components, and data models.

Functional Module Layer : Provides unified wrappers for third‑party interfaces and protocols, making integration transparent.

UI Component Layer : Encapsulates common reusable UI components.

Base Support Layer : Holds third‑party SDKs and APIs.

Implementation :

1. Base Support Layer

Contains the minimal units required by the application, such as third‑party libraries and API interfaces.

2. Base Functional Module Layer

Classifies and abstracts similar third‑party functionalities into unified interfaces and protocols, reducing coupling and simplifying developer interaction.

Abstract similar third‑party interface protocols.

Design modules focused on a single function.

Achieve transparent usage of third‑party interfaces.

3. UI Component Layer

Encapsulates common UI components to avoid redundant view creation and to manage lifecycle differences, following patterns such as the Flyweight pattern.

Avoid repeated view creation and destruction.

Separate view lifecycle management from business logic.

4. Business Logic Layer

Designed for continuous business changes without modifying existing code; it isolates immutable elements, abstracts mutable ones, and provides clear, simple module interfaces.

Modules focus on a single business function.

Distinguish immutable from mutable factors.

Simple, clear module interfaces for easy integration.

Encapsulate immutable aspects as much as possible.

5. Three‑Dimensional Framework Layer

The framework aims to quickly output apps; when the base framework cannot meet new requirements, extensions are added to the functional, UI, or business layers.

Base architecture provides foundational feature encapsulation and abstraction.

Business app extension layer builds on the base framework to add unmet features.

App layer combines and packages components into a new application.

6. Architecture Layer Dependency Calls

Call sequencing is crucial; the design avoids lower layers calling higher layers, same‑level mutual dependencies, and cross‑layer holding, favoring star‑shaped over mesh structures.

Avoid lower‑layer calling higher‑layer.

Avoid same‑level mutual references.

Avoid cross‑layer holding.

Prefer star topology over mesh.

Architecture Optimization Considerations :

Apply solid design principles: composition over inheritance, Open/Closed, Liskov Substitution, Dependency Inversion, Single Responsibility, Interface Segregation, and Law of Demeter.

Focus on simplicity, reduced coupling, and extensibility.

Encapsulate modules with their own input/output models to prevent excessive dependencies.

Distinguish between "is‑a" and "has‑a" relationships for proper composition or inheritance.

Avoid over‑engineering and unrealistic expectations.