Reading.CleanArchiteture.ScreamingArchiteture

SCREAMING ARCHITECTURE

(Clean Architecture by Robert C. Martin)

The “Screaming Architecture” concept in Clean Architecture emphasizes that the primary purpose of a software system—its business intent—should be immediately clear from its structure and organization. This chapter challenges traditional, technology-centric design approaches and advocates for systems that prioritize domain and business logic.


Key Ideas in Screaming Architecture

1. What Should Your Architecture Scream?

  • Your architecture should “scream” its use cases and business rules.
  • When looking at the system’s structure, developers should immediately understand what the system does, not how it is implemented.
  • The architecture should reflect the business domain and the problem the system is solving.

For example:

  • In an e-commerce system, your project structure might include:
    • Orders/
    • Products/
    • Customers/
  • This indicates the system’s purpose as an e-commerce platform.

Bad Example:

  • Organizing around technical concerns like:
    • Controllers/
    • Services/
    • Repositories/
  • This structure hides the purpose of the system, focusing instead on implementation details.

2. Avoid Framework-Centric Design

  • Frameworks often encourage project structures that prioritize their usage over the system’s domain.
  • A framework-centric design might look like:
- Controllers/
- Models/
- Views/
  • While this might work for simple applications, it obscures the business logic in larger systems, making them harder to understand and maintain.

Solution:

  • Treat frameworks as tools, not the foundation of your architecture.
  • Encapsulate frameworks within the system, ensuring they don’t dictate its structure.

3. Organize by Business Use Cases

  • A use-case-driven organization groups code around features or business concerns.
  • Good Example:
- Billing/
    - ProcessPaymentUseCase.java
    - Invoice.java
- CustomerManagement/
    - RegisterCustomerUseCase.java
    - Customer.java
- Inventory/
    - CheckStockUseCase.java
    - InventoryItem.java

This structure emphasizes what the system does and aligns with its business goals.

4. The Problem with Layered Architectures

  • Traditional layered architectures organize code into technical layers like:
    • Controllers/
    • Services/
    • Repositories/
  • This can lead to:
    • Loss of focus on the business domain.
    • Tight coupling between layers.
    • Difficulty navigating the system and understanding its purpose.

Alternative:

  • Use layers to support domain-focused modules but organize your system around use cases and business concerns.

5. The Role of Use Cases

  • Use cases are central to the system’s behavior and define how business rules are executed.
  • Organizing around use cases ensures that the architecture is focused on the what rather than the how.

Example:

  • Instead of having a generic Service layer, define specific use cases like:
    • RegisterUser
    • ProcessOrder
    • GenerateReport

6. Testing the “Scream”

  • To evaluate whether your architecture screams its intent:
    • Look at the top-level directory or package structure.
    • Ask: “Does this structure immediately reveal what the system does?”
  • If it doesn’t, reorganize the structure around the system’s purpose.

Examples of Screaming Architecture

E-Commerce System (Good Design)

- Orders/
    - PlaceOrderUseCase.java
    - Order.java
- Customers/
    - RegisterCustomerUseCase.java
    - Customer.java
- Products/
    - AddProductUseCase.java
    - Product.java

E-Commerce System (Bad Design)

- Controllers/
    - OrderController.java
    - CustomerController.java
- Services/
    - OrderService.java
    - CustomerService.java
- Repositories/
    - OrderRepository.java
    - CustomerRepository.java
  • This structure reflects technical implementation details rather than the business domain.

Benefits of Screaming Architecture

  1. Clarity: Developers can immediately understand the system’s purpose.
  2. Maintainability: Business logic is easy to find, update, and extend.
  3. Domain Focus: Prioritizing use cases ensures alignment with business goals.
  4. Framework Independence: The system is not tied to specific frameworks, making it adaptable to changes.

Key Takeaways

  1. Scream the Business Purpose:
    • Organize your architecture around what the system does, not the tools it uses.
  2. Use Case-Driven Design:
    • Focus on use cases and business concerns rather than technical layers.
  3. Frameworks Are Tools:
    • Don’t let frameworks dictate the structure of your system.
  4. Test the Scream:
    • Your architecture should immediately convey its intent when viewed.
This entry was posted in Без рубрики. Bookmark the permalink.