terminal

codeando_simple

terminal

menu

terminal

search_module

guest@codeandosimple: ~/system/search $ grep -r "" .

Press [ENTER] to execute search

Status

Engine: Ready

Database: Online

Index: V2.1.0_LATEST

bash -- cat clean-architecture.md
guest@codeandosimple: ~/blog/architecture $ cat clean-architecture.md

Clean Architecture_

// "Controlling complexity is the essence of programming" - Brian Kernighan

Clean Architecture is a term introduced by Robert C. Martin (Uncle Bob) as a software design approach that focuses primarily on two points: the separation of concerns and domain independence.

For this, it distinguishes two parts:

  • The Core: The main part, which gives meaning and origin to the system, the business logic, the use cases.

  • The Details: Everything external, the technology, the tools (frameworks, UI, database, external systems) allow the system to function but are not part of the business logic.

# Fundamental Principles

  • Framework Independence: The system should not depend on the existence of any particular software library. It allows using frameworks as tools.

  • Testable: Business logic can be tested without the UI, the database, or the web server.

  • UI and DB Independence: Both the user interface and the database engine can change without affecting the Core.

# Structure

Concentric Circles of Clean Architecture
  1. 1

    Entities (Enterprise Business Rules): Contain the most general and high-level business rules.

  2. 2

    Use Cases (Application Business Rules): Application-specific business logic. They orchestrate the data flow.

  3. 3

    Interface Adapters: Convert data between the format convenient for use cases and external mechanisms.

  4. 4

    Frameworks and Drivers: External layer with databases, web frameworks, etc.

The Dependency Rule

Source code dependency flows from the outside in. What's on the inside knows nothing about what's on the outside.

# Typical Scenario

Data Flow in Clean Architecture

The Controller takes user input, packages it, and passes it through an InputBoundary interface to the UseCaseInteractor. The latter uses the Entities and DataAccess to process the request and returns OutputData to the Presenter, who prepares the data for the View.

# Advantages

  • verified

    Flexibility

    Components can be changed with little impact on other parts.

  • verified

    Sustainability

    Total independence from frameworks that could become obsolete.

# Disadvantages

  • warning

    Over-engineering

    It can be excessive for very simple applications.

  • warning

    Initial Cost

    Requires more architecture and development time at the beginning.

# Example: E-commerce

E-commerce Package Structure

Entities: Order.java

package ecommerce.domain;

public class Order {
    private Product product;
    private int quantity;

    public Order(Product product, int quantity) {
        this.product = product;
        this.quantity = quantity;
    }
}

Use Case: AddProductToCartInteractor.java

package ecommerce.usecases;

public class AddProductToCartInteractor {
    private OrderRepository repository;
    private OrderOutputBoundary presenter;

    public void add(Order order) {
        // Logic to add product to the cart
        repository.saveOrder(order);
        presenter.presentOrderConfirmation(order);
    }
}

Presenter: OrderPresenter.java

package ecommerce.presenter;

public class OrderPresenter implements OrderOutputBoundary {
    @Override
    public void presentOrderConfirmation(Order order) {
        System.out.println("Order confirmed: " + order.getProduct().getName());
    }
}

# Conclusions

Robert Martin's Clean Architecture provides a solid framework for building systems with high cohesion and low coupling, applying principles like SOLID to achieve long-term sustainable applications.