Top 18 Clean Architecture Interview Questions And Answers

Question 1

Explain the Data Flow in Clean Architecture

Accepted Answer

1. UI calls a method from Presenter/ViewModel.
2. Presenter/ViewModel executes the Use case.
3. Use case combines data from User and Post Repositories.
4. Each Repository returns data from a Data Source (Cached or Remote).
5. Information flows back to the UI where we display the list of posts.

![https://miro.medium.com/v2/resize:fit:720/format:webp/1*jH0iI7-MSQYgLUrqTUm6mg.png](https://miro.medium.com/v2/resize:fit:720/format:webp/1*jH0iI7-MSQYgLUrqTUm6mg.png)

Question 2

What is an _Entity_ in Clean Architecture?

Accepted Answer

An **Entity** is an object within our software that represents the union of _critical business rules_ operating on _critical business data_ (i.e. data bound to behaviour if you may). For example,the _Loan_ entity could look like:

- The entity should either hold the _critical business data_ OR have very easy access to it.
- The entity does not know anything about databases, user interfaces or third-party frameworks.
- In an object-oriented language the entity may be a class, but in other paradigms it can be whatever construct allows to bind data and behaviour together (all programing paradigms have this concept).

Question 3

How you pass data between modules where they have different models in Clean Architecture?

Accepted Answer

You simply use **mappers**. Mappers transform DTOs into domain models and vice versa. The reason to make each module has its own models or entities is to easily test each module separately.

Question 4

What do you understand by _Clean Architecture_ approach?

Accepted Answer

The majority of architectural approaches (like Onion or Hexagonal Architecture) have this common set of characteristics:

The architectural approach shall be:

- **Independent of any tech frameworks**
- **Testable**: business rules are testable without the UI, the DB, the web server, and any other external element.
- **Independent of the UI:** The UI can change easily with no impact on the business rules. The UI can easily be replaced.
- **Independent of the database**
- **Independent of external agents:** The business rules don't know anything about interfaces to the outside world.

**The Clean Architecture** is an attempt at integrating all these architectures into a single actionable idea:

![https://github.com/serodriguez68/clean-architecture/raw/master/images/part-5/clean-architecture.png](https://github.com/serodriguez68/clean-architecture/raw/master/images/part-5/clean-architecture.png)

Question 5

Explain the purpose of Clean Architecture _Inner_ and _Outer_ layers

Accepted Answer

- The **Entities** layer contains the domain objects that are used by the Use Cases layer to perform its business logic. These objects are typically plain old data objects (PODOs) that hold the data for the system, and may also include methods for manipulating that data.
- The **Use Cases (interactors)** layer is the first layer of the Clean Architecture system. It is responsible for handling the _business_ logic of the application. The Use Cases layer should be focused on a specific business requirement or action, and should not contain any infrastructure or presentation logic.
- The **Interface Adapters** layer is responsible for adapting the objects in the Entities layer to the outside world. It contains the code that maps between the internal data structures of the system and the external data structures that are used by the user interface or other external systems. 
  - **Gateway (often Repository)** in the 3rd layer is responsible for interaction with DB and external libraries.
  - **Presenter** is responsible for interaction with the UI (View). The presenter has a Reactive Property that publishes Entity updates so that the UI View can be updated without any dependency by subscribing to the property.
- The **Framework & Drivers** layer is responsible for providing the infrastructure and services that the other layers _depend on_. This layer contains the code for interacting with databases, web services, and other external systems.
  - **View** is responsible for manipulating the UI, i.e. inputting actions through the UI and outputting the update of Entity. The view can’t have any dependency on the components in the other layers.

![https://miro.medium.com/v2/resize:fit:720/format:webp/1*ciZo12492A4_iba7kC1Q-Q.png](https://miro.medium.com/v2/resize:fit:720/format:webp/1*ciZo12492A4_iba7kC1Q-Q.png)

Question 6

What is the difference between the _Clean_ and the _N-Tier_ Architectures?

Accepted Answer

Both architectural styles apply layers to separate concerns, however, they do that in a different way:

- The **N-tier Architecture** is about communicating with the database through layers of business logic and representation. It is tightly coupled to the externals (3rd party frameworks/drivers) you want to use, for example to an HTTP Server, an ORM, or an SQL driver.
    
- The **Clean Architecture** is about implementing use cases and building layers of adapters and externals (3rd party frameworks/drivers) around them. It is loosely coupled to the externals you want to use because of the layer of the adapters and DI.

So essentially, When you opt for DI and use interfaces to decouple dependencies in your N-tier architecture, you are transforming your architecture to Onion Architecture. As long as you are observing the direction (and in my case the depth) of your dependencies you moving it to Clean Architecture.

Question 7

Explain what is _Interface Segregation Principle (ISP)_ in Clean Architecture and what are some of its benefits?

Accepted Answer

The general wisdom is:

> Depending on something that carries baggage that you don’t need can cause you troubles that you didn't expect.

The **Interface Segregation Principle (ISP)** is a design principle in object-oriented programming that emphasizes the importance of keeping interfaces segregated or divided into smaller, cohesive units. It suggests that clients (users or classes) should not be forced to depend on interfaces they do not use.

![https://github.com/serodriguez68/clean-architecture/raw/master/images/part-3/isp-in-programming-languages.png](https://github.com/serodriguez68/clean-architecture/raw/master/images/part-3/isp-in-programming-languages.png)

As an example consider the _Repository_ interface.

To apply the **Interface Segregation** principle you shall provide your own repository interface that is dedicated to one use case will help to decouple use cases from each other. If all use cases use the same _Repository_ interface, then this interface accumulates all the methods of all use cases. You can easily break one use case by changing the method of this interface.

So I usually apply the interface segregation principle and create repository interfaces named after the use case. E.g.

```java
public interface PlaceOrderRepository {
     public void storeOrder(Order order);
}
```

and another use case's interface might look like this:

```java
public interface CancelOrderRepository {
     public void removeOrder(Order order);
}
```

Question 8

What are _Use Cases_ in Clean Architecture?

Accepted Answer

**Use Cases** are business rules that _make_ or _save_ money by defining the way the _automated_ system operates. They wouldn't exist if the business operated in a manual environment.

- Each use case is a description of the way the system is used.
- They specify the input provided by the user, the processing steps and the output returned.
    - It uses other data elements to represent input data and output data. See [Requests and Response Models](https://github.com/serodriguez68/clean-architecture/blob/master/part-5-1-architecture.md#requests-and-response-models).
- They specify how and when the [Entities'](https://github.com/serodriguez68/clean-architecture/blob/master/part-5-1-architecture.md#entities-application-independent-business-rules) Critical Business Rules are invoked.
    - Entities have no knowledge of the use cases that control them. Entities are at a higher-level than use cases and therefore **do not depend** on them.
- It does NOT describe the user interface. It only specifies the data to be passed in. Use cases don't know if they are part of a web-system, a desktop client, etc.
- A use case is an object that has one or more functions that implement the application-specific business rules.

Question 9

Explain the _control flow_ of a user interacting with Clean Architecture components?

Accepted Answer

Following the purple arrow we can see the control flow of a user interacting with a system:

1. The user interacts with the view.
2. The view creates a request (object) which is passed to the controller.
3. The controller converts the request into a request model and passes it to the use case interactor through its input port.
4. The use case interactor processes the request model and creates a response model which is passed through the output port to the presenter.
5. The presenter converts the response model to the view model which is then passed to the view.
6. The user sees the result of his interaction in the view.

![https://plainionist.github.io/assets/clean-architecture/User.Interactor.Flow.png](https://plainionist.github.io/assets/clean-architecture/User.Interactor.Flow.png)

- The left (blue) section where the frameworks live (e.g. an HTML/JavaScript view)
- The middle (green) section where the adapters live (controllers and presenters)
- The right (red) section where the business logic (use case interactors) live

The controller and the presenter are located in the middle of this picture and they appear as a bridge between the user’s world (the view) and the business logic’s world (interactors).

Question 10

Where should I implement the _external API calls_ logic in Clean Architecture?

Accepted Answer

Obtaining the images and reviews from the perspective of your product use case is just like database access. The only difference is that you don't query a database, you query another service instead.

When you take a look at the clean architecture you will realize that the controllers and gateways are on the same architectural layer - the **interface adapters**. This layer is named "interface adapters" because it adapts interfaces of the lower layer.

As you can see gateways can be a DB or an external interface (a service).

[![Gateways, DBs and external services of the clean architecture](https://i.stack.imgur.com/1c9Nq.png)](https://i.stack.imgur.com/1c9Nq.png)

Thus you should structure your application in this way:

```javascript
                       +------------------+
                       | product use case |
                       +------------------+
                                |
             +------------------+---------------------+
             |                  |                     |
             V                  V                     V
    +-----------------+ +------------------+ +-------------------+
    | ImageRepository | | ReviewRepository | | ProductRepository |
    +-----------------+ +------------------+ +-------------------+
            ^                     ^                    ^
            |                     |                    |
 ===========+=====================+====================+================
            |                     |                    |
 +--------------------+ +--------------------+ +--------------------+
 |   ImageRestClient  | | ReviewRestClient   | |   JDBCConnector    |
 +--------------------+ +--------------------+ +--------------------+
```

Easy to test and if you decide one day that the images should be managed in the product microservice instead of a separate service you can replace the `ImageRestClient` with a `JDBCConnector`.

Top 18 Clean Architecture Interview Questions

What is an Entity in Clean Architecture?

What do you understand by Clean Architecture approach?

How you pass data between modules where they have different models in Clean Architecture?

Explain the Data Flow in Clean Architecture

Explain what is Interface Segregation Principle (ISP) in Clean Architecture and what are some of its benefits?

What do you mean by Clean Architecture is Screaming?

What are Use Cases in Clean Architecture?

Explain what is Dependency Rule in Clean Architecture

Explain the purpose of Clean Architecture Inner and Outer layers

What is the difference between the Clean and the N-Tier Architectures?

How shall we integrate DB Layer access in Clean Architecture?

Where should I implement the external API calls logic in Clean Architecture?

Explain the control flow of a user interacting with Clean Architecture components?

What is the role of the Controller in Clean Architecture?

What is the role of the Presenter in Clean Architecture?

Compare Onion vs Clean vs Hexagonal Architectures

What is the difference between Request/Response Models and Entities in Clean Architecture?

How and where do you use transactions in the Clean Architecture?