Clean Architecture layers in LLD - System Design Exercise

Design: Clean Architecture Layered System

Design the layered architecture and explain responsibilities of each layer. Do not cover specific UI or database implementations.

Functional Requirements

FR1: Separate the system into clear layers to improve maintainability and testability

FR2: Ensure dependencies only point inward, from outer layers to inner layers

FR3: Allow easy replacement of UI, database, or external services without affecting core logic

FR4: Support independent testing of business rules without UI or database dependencies

Non-Functional Requirements

NFR1: System must handle up to 1000 concurrent users

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime

NFR4: Code changes in one layer should not require changes in other layers

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Entities (business rules)

Use Cases (application logic)

Interface Adapters (controllers, presenters, gateways)

Frameworks and Drivers (UI, database, external services)

Design Patterns

Dependency Rule (dependencies point inward)

Ports and Adapters (Hexagonal Architecture)

Inversion of Control

Separation of Concerns

Reference Architecture

  +-----------------------+
  |   Frameworks & Drivers |
  |  (UI, DB, External)   |
  +-----------+-----------+
              |
  +-----------v-----------+
  |  Interface Adapters   |
  | (Controllers, Presenters, Gateways) |
  +-----------+-----------+
              |
  +-----------v-----------+
  |      Use Cases        |
  |  (Application Logic)  |
  +-----------+-----------+
              |
  +-----------v-----------+
  |       Entities        |
  |   (Business Rules)    |
  +-----------------------+

Components

Entities

Plain classes or data structures

Represent core business rules and data. Independent of UI or database.

Use Cases

Application service classes

Implement application-specific business rules and orchestrate entities.

Interface Adapters

Controllers, Presenters, Gateways

Convert data between use cases and external formats (UI, DB).

Frameworks and Drivers

Web frameworks, databases, external APIs

Provide UI, database access, and external service integration.

Request Flow

1. User interacts with UI in Frameworks and Drivers layer.

2. UI sends request to Controller in Interface Adapters layer.

3. Controller converts request to use case input and calls Use Cases layer.

4. Use Cases execute business logic using Entities layer.

5. Entities enforce business rules and return results to Use Cases.

6. Use Cases return output to Presenter in Interface Adapters.

7. Presenter formats data for UI and sends response back through Frameworks and Drivers.

8. Database gateways in Interface Adapters access database in Frameworks and Drivers as needed.

Database Schema

Not applicable - Clean Architecture focuses on layering and separation, not specific database design.

Scaling Discussion

Bottlenecks

Tight coupling between layers can reduce flexibility and increase bugs.

Slow database or external service calls in Frameworks and Drivers can increase latency.

Complex use cases can become hard to maintain if not well separated.

Testing can be difficult if layers are not properly isolated.

Solutions

Enforce strict dependency rules and use interfaces to decouple layers.

Use caching and asynchronous calls to reduce latency from external services.

Keep use cases small and focused; split complex logic into smaller use cases.

Write unit tests for Entities and Use Cases; use mocks for Interface Adapters.

Interview Tips

Time: Spend 10 minutes explaining the layers and their responsibilities, 10 minutes on data flow and dependency rules, 10 minutes on scaling and testing strategies, and 15 minutes answering questions.

Explain the Dependency Rule and why dependencies point inward.

Describe responsibilities of each layer clearly.

Show how this architecture improves maintainability and testability.

Discuss how to isolate business logic from UI and database.

Mention how to handle scaling and performance bottlenecks.

Practice

1. Which layer in Clean Architecture contains the core business rules and logic?

easy

A. UI layer

B. Entities layer

C. Database layer

D. Frameworks layer

Solution

1. Step 1: Understand the role of each layer

   The Entities layer holds the core business rules and logic, independent of external concerns.

2. Step 2: Identify the correct layer for business logic

   UI, Database, and Frameworks layers handle external interactions, not core logic.

3. Final Answer:

   Entities layer -> Option B

4. Quick Check:

   Business logic = Entities layer [OK]

Hint: Core logic always lives in the Entities layer [OK]

Common Mistakes:

• Confusing UI layer with business logic
• Thinking database layer contains core rules
• Mixing frameworks with core logic

2. In Clean Architecture, which layer is responsible for adapting data from the database to the business logic?

easy

A. Entities layer

B. Use Cases (Interactor) layer

C. UI layer

D. Interface Adapters layer

Solution

1. Step 1: Identify the role of Interface Adapters

   Interface Adapters convert data from external sources like databases into a form usable by inner layers.

2. Step 2: Confirm other layers' roles

   Entities hold business rules, Use Cases orchestrate logic, UI handles presentation, so adapting data fits Interface Adapters.

3. Final Answer:

   Interface Adapters layer -> Option D

4. Quick Check:

   Data adaptation = Interface Adapters [OK]

Hint: Data conversion happens in Interface Adapters [OK]

Common Mistakes:

• Choosing Entities layer for data adaptation
• Confusing Use Cases with data conversion
• Selecting UI layer for database data handling

3. Given the following flow in Clean Architecture: UI calls Use Cases, which then call Entities. What is the correct order of dependency direction?

medium

A. UI -> Entities -> Use Cases

B. Entities -> Use Cases -> UI

C. UI -> Use Cases -> Entities

D. Use Cases -> UI -> Entities

Solution

1. Step 1: Understand dependency rule in Clean Architecture

   Dependencies always point inward, from outer layers to inner layers.

2. Step 2: Apply to given flow

   UI depends on Use Cases, which depend on Entities, so direction is UI -> Use Cases -> Entities.

3. Final Answer:

   UI -> Use Cases -> Entities -> Option C

4. Quick Check:

   Dependency direction = UI to Entities [OK]

Hint: Dependencies always point inward [OK]

Common Mistakes:

• Reversing dependency direction
• Confusing which layer calls which
• Assuming Entities depend on UI

4. A developer placed database access code directly inside the Entities layer. What is the main problem with this design?

medium

A. Entities layer should not depend on external frameworks or databases

B. Entities layer must handle UI rendering

C. Database code belongs only in the UI layer

D. Entities layer should only contain database schemas

Solution

1. Step 1: Recall Clean Architecture dependency rules

   Inner layers like Entities must be independent of external concerns like databases.

2. Step 2: Identify why database code in Entities is wrong

   It creates tight coupling and breaks separation of concerns.

3. Final Answer:

   Entities layer should not depend on external frameworks or databases -> Option A

4. Quick Check:

   Entities layer independence = true [OK]

Hint: Keep Entities free from external dependencies [OK]

Common Mistakes:

• Thinking Entities handle UI
• Placing database code in UI layer
• Confusing database schemas with business logic

5. You need to design a system where the UI can be changed without affecting business rules, and the database can be swapped easily. Which Clean Architecture principle helps achieve this?

hard

A. Dependency Rule: Inner layers do not depend on outer layers

B. UI layer directly accesses Entities for faster updates

C. Database layer contains business logic for flexibility

D. Use Cases layer handles UI rendering and database access

Solution

1. Step 1: Identify the principle for independence

   The Dependency Rule states inner layers (business rules) do not depend on outer layers (UI, database).

2. Step 2: Explain how this helps system flexibility

   This separation allows changing UI or database without impacting core business logic.

3. Final Answer:

   Dependency Rule: Inner layers do not depend on outer layers -> Option A

4. Quick Check:

   Dependency Rule ensures flexibility [OK]

Hint: Inner layers must be independent for easy changes [OK]

Common Mistakes:

• Allowing UI to access Entities directly
• Putting business logic in database layer
• Mixing UI rendering with Use Cases