15 Common Clean Architecture Interview Questions (ANSWERED) For Software Architects and Devs

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:

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).

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.

• 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).

• 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.

The Dependency Rule states that source code dependencies should always point inward toward higher-level policies or abstractions and should never point outward toward lower-level details or implementations. In other words, the dependencies between different components or modules of a system should follow a specific direction, with higher-level modules depending on lower-level ones, but not the other way around.

• Presentation Layer depends on Domain Layer.
• Data Layer depends on Domain Layer.
• Domain Layer does NOT depend on Data/Presentation Layer.

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.

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.

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

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

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

Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes functions and classes. variables, or any other named software entity.

For DB Layer you create a technology-independent interface in the use case layer and implement it in the gateway layer:

public interface OrderRepository {
    public List<Order> findByCustomer(Customer customer);
}

implementation is in the gateway layer

public class HibernateOrderRepository implements OrderRepository {
      ...
}

At runtime, you pass the gateway's implementation instance to the use case's constructor. That would not violate the dependency rule, because the use cases define the interface they need.

It might be even better to extract these use cases' interfaces into their own module. This prevents the db module to depend on the dependencies of the use case module.

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.
• They specify how and when the Entities' 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.

One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. According to Uncle Bob an architecture “screams” when it clearly expresses its core business purpose.

The top-level folder structure, the project/DLL names, and the namespaces should express business aspects rather than frameworks or other details. That also means that the top-level structure and names should express your business domain and not the technical details and frameworks you use.

Consider non-screaming folder structure:

Consider screaming folder structure:

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.

The controller takes user input, converts it into the request model defined by the use case interactor, and passes this to the same.

The request object accepted by the controller is defined by the controller. We do NOT want the controller to depend on the view or types defined in the framework circle. Such request objects are usually simple data transfer objects (DTO).

The job of the Presenter is to repackage the OutputData (Response Model) into viewable form as the ViewModel, which is yet another plain old Java object (POJO). The ViewModel contains mostly Strings and flags that the View uses to display the data. Whereas the OutputData may contain Date objects, the Presenter will load the ViewModel with corresponding Strings already formatted properly for the user.

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).

Thus you should structure your application in this way:

                       +------------------+
                       | 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.