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
- Clarity: Developers can immediately understand the system’s purpose.
- Maintainability: Business logic is easy to find, update, and extend.
- Domain Focus: Prioritizing use cases ensures alignment with business goals.
- Framework Independence: The system is not tied to specific frameworks, making it adaptable to changes.
Key Takeaways
- Scream the Business Purpose:
- Organize your architecture around what the system does, not the tools it uses.
- Use Case-Driven Design:
- Focus on use cases and business concerns rather than technical layers.
- Frameworks Are Tools:
- Don’t let frameworks dictate the structure of your system.
- Test the Scream:
- Your architecture should immediately convey its intent when viewed.