Clean Architecture

Important Points About Architecture:

• The shape that the software will have
• Division of components
• Communication between components
• A good architecture facilitates development, deployment, operation, and maintenance

Goals of a Good Architecture:

• The main goal of architecture is to support the system lifecycle. A good architecture makes the system easy to understand, develop, maintain, and deploy. The ultimate goal is to optimize the system’s lifecycle cost and maximize developer productivity.

Rules vs Details:

• Business rules bring real value to the software
• Details support the rules
• Details should not impact business rules
• Frameworks, databases, and APIs should not impact business rules

Use Cases:

• Intention
• Clarity of each software behavior

Use Cases - SRP:

• There is a tendency to “reuse” use cases because they seem very similar
• Example: Update vs Insert. Both check if a record exists and persist data. But they are different use cases. Why?
• SRP (Single Responsibility Principle) ⇒ They change for different reasons
• Use cases tell a story

Architectural Boundaries:

• Everything that does not directly impact business rules should be in a different architectural boundary. Example: frontend or database changes should not affect business rules

Input vs Output:

• At the end of the day, everything comes down to an Input that produces an Output
• Simplify your thinking by always focusing on Input and Output

DTO (Data Transfer Object):

• Used to transfer data across architectural boundaries

• Anemic object, without behavior

• Contains data (input or output)

• Does not contain business rules

• Does not have behavior

• Its only purpose is to carry data

• Flow:

  • API → Controller → Use Case → Entity
  • Controller creates a DTO with input data and sends it to the Use Case
  • Use Case executes logic, creates an output DTO, and returns it to the Controller

Presenters:

• Transformation objects
• Adapt the output DTO into the correct format for delivery
• A system can support multiple output formats: XML, JSON, Protobuf, GraphQL, CLI, etc.

Entities:

• Clean Architecture Entities ≠ DDD Entities
• In Clean Architecture, entities represent the business rules layer
• They apply across different scenarios
• There is no strict definition of how to create them
• Usually implemented using DDD tactical patterns
• Entities = Aggregates + Domain Services