Reading.CleanArchitecture.PartialBoundaries

Key Concepts of Chapter 24

1. What Are Partial Boundaries?

  • Definition: Partial boundaries are less rigid separations between components or layers in a system.
  • Instead of fully isolating layers or modules, partial boundaries allow some controlled leakage of details to reduce complexity or overhead.
  • They are useful in situations where enforcing strict boundaries would lead to diminishing returns.

2. Why Use Partial Boundaries?

  • Pragmatism: Strict boundaries can sometimes introduce unnecessary complexity, especially for smaller or simpler systems.
  • Performance: Fully abstracting boundaries may result in performance overhead that isn’t justified in certain contexts.
  • Team Constraints: Smaller teams may lack the resources to implement and maintain a fully decoupled architecture.
  • Development Speed: Partial boundaries can speed up development by simplifying interactions between layers.

3. Examples of Partial Boundaries

Database Access:
  • A fully abstracted repository pattern might be overkill for simple CRUD applications.
  • Instead of abstracting all database queries, you might allow some queries to reside closer to the application logic.

Partial Boundary Example:

public class UserService {
    private Database database;

    public User getUserById(int userId) {
        return database.query("SELECT * FROM users WHERE id = ?", userId);
    }
}
UI Layer:
  • For simpler applications, some UI logic may interact directly with use cases or even entities, bypassing strict boundaries.
  • Example: A view might directly access a data model to render content.
External Systems:
  • Instead of fully abstracting an external API behind interfaces, you might call the API directly within the use case for simplicity.

4. Risks of Partial Boundaries

  • Coupling: Partial boundaries can lead to tighter coupling between components, making future changes harder.
  • Reduced Testability: Direct dependencies between layers might complicate testing.
  • Technical Debt: Over-reliance on partial boundaries can create long-term maintenance challenges.

5. When to Use Partial Boundaries

  • Simple Systems: When the application has limited complexity and well-defined requirements.
  • Prototyping: During early stages of development when speed is more important than architectural purity.
  • Low-Risk Areas: For parts of the system that are unlikely to change frequently or impact core business rules.

6. Evolving from Partial to Full Boundaries

  • Martin emphasizes that partial boundaries should not become permanent unless justified.
  • As the system grows or requirements change, you may need to refactor partial boundaries into fully abstracted ones.
  • Incremental Refactoring:
    • Replace direct database calls with repository interfaces.
    • Move business logic out of the UI layer into use cases.

Example: E-Commerce System

Partial Boundary (Pragmatic):

public class ProductService {
    private Database database;

    public List<Product> getProductsByCategory(String category) {
        return database.query("SELECT * FROM products WHERE category = ?", category);
    }
}

Full Boundary (Abstracted):

public interface ProductRepository {
    List<Product> findByCategory(String category);
}

public class ProductService {
    private ProductRepository productRepository;

    public ProductService(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    public List<Product> getProductsByCategory(String category) {
        return productRepository.findByCategory(category);
    }
}

Key Takeaways

  1. Balance Purity and Practicality:
    • Use partial boundaries when full boundaries introduce unnecessary complexity or overhead.
  2. Understand the Risks:
    • Be aware of the trade-offs, such as reduced testability and tighter coupling.
  3. Evolve Over Time:
    • Start with partial boundaries and refactor to full boundaries as the system grows or requirements change.
  4. Keep Business Rules Independent:
    • Even with partial boundaries, core business rules should remain isolated from external systems and implementation details.
This entry was posted in Без рубрики. Bookmark the permalink.