Reading.CleanArchitecture.BusinessRules

1. What Are Business Rules?

  • Definition: Business rules are the policies, procedures, and logic that define how a business operates and achieves its goals.
  • Examples:
    • “A customer cannot place an order if their credit limit is exceeded.”
    • “An employee must work at least 40 hours per week to qualify for overtime.”
  • These rules are the most critical part of your system and must be independent of implementation details like frameworks, databases, or UI.

2. Types of Business Rules

  • Entity Rules:
    • Define the behavior and constraints of individual entities (e.g., a Customer or an Order).
    • Example: “An order must have at least one item.”
  • Application Rules:
    • Define workflows and processes specific to the application.
    • Example: “Notify the warehouse when an order is placed.”

3. Protecting Business Rules

  • The primary responsibility of the architecture is to protect and encapsulate the business rules.
  • Business rules should be:
    1. Isolated from external systems: They must not depend on the database, UI, or any framework.
    2. Testable: You should be able to test business rules without requiring integration with other layers.

4. Organizing Business Rules

  • Entities (Core Business Rules):
    • Entities represent the high-level, universal rules of the business.
    • These are the most abstract and stable parts of the system.
  • Use Cases (Application-Specific Rules):
    • Use cases implement specific workflows using the entities.
    • They coordinate the interactions between entities, external systems, and other components.

Example:

  • Entity Rule: “A product must have a non-negative price.”
  • Use Case Rule: “When a product is added to the cart, update the cart’s total price.”

5. Independence of Business Rules

  • Business rules must be independent of:
    • Frameworks (e.g., Spring, React).
    • Databases (e.g., SQL, NoSQL).
    • UI technologies (e.g., web, mobile apps).
  • This independence ensures that the rules can be reused, tested, and modified without being affected by changes in external systems.

6. Business Rules in Layered Architecture

  • Business rules reside in the domain layer (entities) and the application layer (use cases).
  • Other layers (e.g., UI, database) should depend on the business rules, not the other way around.

Layer Responsibilities:

  • Domain Layer: Encapsulates core business rules.
  • Application Layer: Defines workflows using domain rules.
  • Interface Adapters: Translates between the domain/application layers and external systems.
  • Frameworks and Drivers: Provides implementation details (e.g., database queries, HTTP endpoints).

7. Examples of Business Rule Protection

Example 1: E-Commerce System

Entity Rule: “An order must have at least one valid product.”

public class Order {
    private List<Product> products;

    public void addProduct(Product product) {
        if (product.isValid()) {
            products.add(product);
        } else {
            throw new IllegalArgumentException("Invalid product.");
        }
    }
}

Use Case Rule: “Notify the warehouse when an order is placed.”

public class PlaceOrderUseCase {
    private OrderRepository orderRepository;
    private WarehouseService warehouseService;

    public PlaceOrderUseCase(OrderRepository orderRepository, WarehouseService warehouseService) {
        this.orderRepository = orderRepository;
        this.warehouseService = warehouseService;
    }

    public void execute(Order order) {
        orderRepository.save(order);
        warehouseService.notify(order);
    }
}

8. Why Focus on Business Rules?

  • Core Value of the System:
    • Business rules define the value and purpose of your application. They represent the “reason” the software exists.
  • Change Isolation:
    • Changes in UI, frameworks, or databases should not require changes to business rules.
  • Longevity:
    • Frameworks and tools come and go, but business rules endure. Protecting them ensures the longevity of your system.

9. Testing Business Rules

  • Since business rules are independent of frameworks and external systems, they are easy to test.
  • Unit tests can verify individual rules (e.g., “An order must have at least one item”).
  • Use case tests can verify workflows (e.g., “When an order is placed, notify the warehouse”).

Key Takeaways

  1. Business Rules Are the Core:
    • They represent the essence of your system and must be protected from external dependencies.
  2. Organize by Type:
    • Separate entity rules (universal constraints) from use case rules (application-specific workflows).
  3. Isolate and Abstract:
    • Keep business rules independent of frameworks, databases, and other implementation details.
  4. Enable Testing:
    • Make business rules easy to test by isolating them from external systems.
  5. Longevity and Adaptability:
    • Protecting business rules ensures the system can adapt to new tools, frameworks, and technologies without losing its purpose.
This entry was posted in Без рубрики. Bookmark the permalink.