Reading.CleanArchitecture.PolicyAndLevel

This chapter focuses on the relationship between policies and levels in software architecture. Robert C. Martin explains how to organize and prioritize policies in layers and levels to create systems that are adaptable, maintainable, and scalable.


1. What Are Policies?

  • Definition: Policies represent the rules and logic that define how a system operates.
  • Examples:
    • Business rules (e.g., “A customer cannot place an order if their credit limit is exceeded”).
    • Application-specific workflows (e.g., “Send a confirmation email after registration”).
  • Policies are central to a system’s behavior and must be protected from dependencies on implementation details (e.g., databases, frameworks).

2. What Are Levels?

  • Levels represent the hierarchical structure of a system’s architecture.
  • At the highest level are the most abstract policies (e.g., core business rules), while the lowest level contains implementation details (e.g., frameworks, UI, and databases).
  • The relationship between levels is governed by the Dependency Rule: Dependencies must point inward, toward higher-level policies.

3. Layering Policies Across Levels

  • Policies are organized into layers based on their level of abstraction:
    1. Entities (Highest Level):
      • Represent the most abstract and universal business rules.
      • Example: Customer or Order entities with rules like “An order must have at least one item.”
    2. Use Cases:
      • Application-specific workflows that dictate how entities are used to fulfill user actions.
      • Example: “Process an order” or “Register a new customer.”
    3. Interface Adapters:
      • Handle translation between the outer layers (UI, database) and the core layers (use cases and entities).
      • Example: Controllers, Presenters, Repositories.
    4. Frameworks and Drivers (Lowest Level):
      • External systems, tools, and details that interact with the system.
      • Example: Web frameworks, SQL databases, APIs.

4. Policy Separation

  • Policies at higher levels should not depend on those at lower levels.
  • This separation ensures:
    • Flexibility: Changing low-level details (e.g., replacing a database) does not affect core business logic.
    • Reusability: Policies in the higher levels can be reused across different contexts or applications.

5. Protecting High-Level Policies

  • High-level policies (e.g., domain rules) must be independent of:
    • Frameworks (e.g., Spring, Rails).
    • Databases (e.g., MySQL, MongoDB).
    • UI technologies (e.g., Angular, React).

Example:

  • The core logic for “calculating discounts” should not depend on a specific database schema or API.

6. Low-Level Policies and Tools

  • Lower-level policies (e.g., database schemas, APIs) are volatile and subject to frequent change.
  • Encapsulate them behind boundaries to minimize their impact on higher-level policies.

7. Real-World Example: E-Commerce Application

  • Entities (Highest Level):
    • Define a Product entity with rules like “A product must have a valid price.”
  • Use Cases:
    • “Place Order” workflow coordinates entities and external dependencies.
  • Interface Adapters:
    • Controllers handle HTTP requests and map them to use cases.
    • Repositories abstract database queries.
  • Frameworks and Drivers (Lowest Level):
    • Frameworks like Spring Boot handle routing and dependency injection.
    • SQL database stores data for the Product and Order entities.

Key Takeaways

  1. Policies Define Behavior:
    • Policies are the rules that govern system behavior and must be protected from implementation details.
  2. Organize by Levels:
    • Use abstraction levels to separate core logic (entities) from application workflows (use cases) and implementation details (frameworks, databases).
  3. Dependency Rule:
    • Dependencies must flow inward toward higher-level policies, ensuring core logic remains independent of external tools.
  4. Protect High-Level Policies:
    • Encapsulate low-level details behind interfaces to ensure that changes in tools or frameworks don’t affect the system’s core behavior.
This entry was posted in Без рубрики. Bookmark the permalink.