Optivem Journal

Optivem Journal

Clean Architecture

Clean Architecture on the Backend: Data Flow

How does data flow through the system?

Valentina Jemuović's avatar
Valentina Jemuović
Oct 31, 2025
∙ Paid
10
2
4
Share

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.


Data flows from external sources (like the UI) to the core logic and back out:

1. Frontend: Send request to Backend

The user enters the SKU and quantity, then clicks “Place Order.” The frontend sends this data to the backend as a REST API request.

2. Backend: Presentation Layer → Use Case

The REST API receives the JSON request, converts it into a Request DTO, and delegates the work to the Use Case. The controller stays minimal and doesn’t contain any business logic.

3. Backend: Use Case → Domain Layer

The Use Case performs basic validation of the Request DTO, and calls repositories to retrieve entities. The Use Case may create or save entities via repositories and can call methods on those entities to execute business logic.

4. Backend: Domain Layer → Use Case

The Domain Layer returns entities and computed results — such as the product details, total order price, and order status — back to the Use Case.

5. Backend: Use Case → Presentation Layer

The Use Case prepares a Response DTO with the processed results from the Domain Layer and sends it to the REST API.

6. Backend: Presentation Layer → Client

The REST API formats the response and returns it to the client (Frontend) for display.

7. Frontend: Present to user

The frontend receives the backend response and displays the order confirmation, showing details like the product, quantity, total price, and order status.

Data Flow

Data flow defines how information moves between the layers of your system — from the user interface, through the business logic, and back out again.

  • Each layer has a single responsibility.

  • Dependencies always point inward, toward the core logic.

  • You can change external details (UI, database, frameworks) without breaking your domain rules.

Real-life Example: Ordering System

Applying Clean Architecture on the backend (for an e-commerce system).

1. Frontend: Send request to Backend

On the Frontend, user inputs the SKU and quantity, and clicks button to “Place Order“. Then Frontend calls the Backend REST API.

Let’s see what are the Clean Architecture Layers are on the Backend.

2. Backend: Presentation Layer → Use Case

On the Backend, the Presentation Layer is generally the REST API (or it might be SOAP Service, or Message Consumer, etc.).

The REST API has received the request as JSON. We have frameworks that automatically convert the JSON into a Request DTO. In the example below, the Request DTO is the PlaceOrderRequest.

We keep the REST API controller minimal. We just pass the Request DTO to the use case. In this case, we pass the PlaceOrderRequest to the PlaceOrderUseCase.

The reason is because the REST API controller should not have knowledge of application/business logic, it just delegates.

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @PostMapping
    public ResponseEntity<PlaceOrderResponse> placeOrder(@RequestBody PlaceOrderRequest request) {
        var response = placeOrderUseCase.execute(request);
        ...
    }
}

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2025 Valentina Jemuović, Optivem
Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture