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 anOrder
). - Example: “An order must have at least one item.”
- Define the behavior and constraints of individual entities (e.g., a
- 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:
- Isolated from external systems: They must not depend on the database, UI, or any framework.
- 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
- Business Rules Are the Core:
- They represent the essence of your system and must be protected from external dependencies.
- Organize by Type:
- Separate entity rules (universal constraints) from use case rules (application-specific workflows).
- Isolate and Abstract:
- Keep business rules independent of frameworks, databases, and other implementation details.
- Enable Testing:
- Make business rules easy to test by isolating them from external systems.
- Longevity and Adaptability:
- Protecting business rules ensures the system can adapt to new tools, frameworks, and technologies without losing its purpose.