Introduction to Clean Architecture for TypeScript: PART4

Refs

• Introduction to Clean Architecture for TypeScript: PART1
• Introduction to Clean Architecture for TypeScript: PART2
• Introduction to Clean Architecture for TypeScript: PART3

Clean Architecture

In this section, we will finally discuss the Clean Architecture.
As we have discussed in this chapter, Clean Architecture focuses on how to protect the core business domain of the product from other dependencies.
Decouple the business domain from specific and changeable technologies such as UI View, DB, and storage.
By doing so, you can protect critical business rules from change and separate business decisions from technology factors.
So how exactly do you protect your business domain from change?
In this section, we will answer that question.

The concentric circles in this figure represent Clean Architecture in a nutshell.
Looking at this diagram, you can see that each layer is arranged in concentric circles with the Entity at the center.
The arrows are drawn from the outside to the inside, which represents the dependency rule.
Then, there is a collection of squares and arrows in the lower right corner of the figure, which represent the reversal of the processing flow and dependencies.
We have already discussed dependency inversion in the section "Dependency Injection", and as you can see in this figure, dependency inversion is a very important concept.

Now, let's take a closer look at the elements that make up the Clean Architecture.

Dependency rules

This figure illustrates concentric circles and the direction of dependencies.
There are business rules called Entities in the center, and layers are arranged in concentric circles around them.
And this diagram contains important rules about dependencies.

Source code dependencies must point only inward, toward higher-level policies.
(Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education. )

To rephrase this rule, we can say that the inner element must not depend on the outer element.
For example, a Use case can depend on an Entity, but the Entity cannot be the details of the Use case.
In this way, the Entity is isolated and protected from outside changes.

In this concentric circle diagram, there is a "outside world of the application" outside the circle.
And the outermost layers, such as the DB and UI, are connected to the outside world.
In general, applications are driven by signals from the outside world, such as user interactions, DB rewrites, and event subscriptions.
In other words, the starting point of the process is the outer boundary of the concentric circle, which propagates toward the center of the circle.
Then, the content processed inside the circle is transmitted to the outside again, and influences the outside world by presenting it to the user or rewriting it in the DB.
To put it another way, the flow of processing starts from the outside of the concentric circles, goes through the inside, and returns to the outside again.
The important thing here is that the flow of processing and dependencies are reversed.

DIP and DI can control this reversal.

Entity

Entities encapsulate enterprise-wide Critical Business Rules.
An entity can be an object with methods, or it can be a set of data structures and functions.
It doesn't matter so long as the entities can be used by many different applications in the enterprise.
(Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education.)

Entities represent the rules of the business that the company is engaged in.
Business rules are the core elements for applications, and they are configured to protect cores.
Entities can be difficult to define clearly.
The definition should be flexible, depending on the business the company is working on and the applications that make it possible.
To think about what an Entity is, especially for an SPA such as a React application, we need to consider
API servers and backend for frontend (BFF) are deeply involved.

Use case

The software in the use cases layer contains application-specific business rules.
(Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education.)

Whereas Entities dealt with the entire business of an enterprise, Use cases deal with the business rules specific to that application.
The Use cases perform the necessary processing for the application while manipulating the Entities.
In other words, Entities abstract the processing across multiple applications, and more abstract rules than Use cases.

Again, how to handle Use cases in building an SPA is a matter of debate.

Framework

In this book, we will focus on a specific view library called React and how to incorporate Clean Architecture ideas into React applications.
However, in fact, the Clean Architecture is designed to be independent of any particular framework or library.
In other words, it doesn't matter whether you use React or Vue.js for Clean Architecture.
This is because the goal of this architecture is to separate frameworks and libraries from the application and make them easy to replace.
Ideally, Clean Architecture should be applied to SPA, and the design should be able to switch between view frameworks (and libraries),
but as a preliminary step, this book will focus on React while understanding that aspect of the Clean Architecture.

Main component

In general, there are several parts of the product code that do not satisfy the Dependency Inversion Principle (DIP).
In other words, there are some components that are dependent on concrete components.
Because concrete components are unstable and prone to change, components that depend on them are also affected by these changes.
Clean Architecture uses DI (Dependency Injection) to reverse dependencies and eliminate dependencies on concrete components.
However, in order to do DI, we need to depend on concrete components.
This is because DI is the process of indicating to an interface which concrete components to use.
Thus, even if DI is applied to DIP violations, the dependency on concrete components will not disappear.
Therefore, we will consider aggregating the dependencies of DI on concrete objects into one place. That part is called Main component.
It is called this because this component often contains the main function.
In other words, we use DI to fix multiple DIP violations in the product code to appropriate dependencies direction and aggregating dependencies on concrete components to Main component.

The dependency on concrete components cannot be completely removed from the product code.
This is because you cannot use a concrete component without depending on it.
Therefore, we can reduce the number of DIP violations by creating an element like Main component that takes care of the dependency on the concrete component.
Of course, it is ideal to aggregate them in one place, but even if that is not the case, we need to aggregate them in as few places as possible.
It is important to take into account the product's characteristics and the team's culture to design where Main components should be and what their roles should be.

About the number and naming of layers

The circles are intended to be schematic: You may find that you need more than just these four. There's no rule that says you must always have just these four. However, the Dependency Rule always applies. Source code dependencies always point inward.
(Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education.)

As Robert C. Martin notes, it is not always right to obediently follow what is written in these concentric circles.
The most important thing is the dependency rule, not the number of concentric layers or their naming.
There is no mention of layer naming in "Clean Architecture".
On the other hand, naming your own unnecessarily would mean throwing away the benefit of following a particular architecture.
This is because one of the advantages of following methods such as DDD or Clean Architecture is that developers who already know those methods for a particular naming can understand the architecture of the application at a glance.
For example, if names such as Entity, Use case, Repository, etc. are used, you can guess what role the module will play without looking at the code details.
Thus, even though we are adopting the Clean Architecture, it can be confusing to give it a different name than the naming of Entity or Use case.
However, SPA and React have a naming culture that has been used traditionally as well.
For example, Store, Dispatcher, Reducer, etc. used in Flux.
How to map these naming cultures to the layered structure of the Clean Architecture is a matter of debate.
This will be key to implementing Clean Architecture in React applications.
These correspondences will be discussed a bit in the original book.

Ads

This article is an excerpt from the first chapter of the book "React Clean Architecture". Some wording has been changed. You can buy the kindle version of this book from amazon.