DEV Community: Imamori Daichi

Dependency Injection for TypeScript

Imamori Daichi — Mon, 20 Sep 2021 07:22:41 +0000

Ref

Abstract

Clean Architecture deals with concentric architecture with the business domain at the core, but
One of the key principles is the dependency constraint, which states that we should only depend on the inside from the outside.
However, in a straightforward implementation, the processing flow and dependencies would be in the same direction.
Of course, the Clean Architecture also requires processing from the inside to the outside, so a straightforward implementation will result in dependencies from the inside to the outside.
In other words, in order to observe the dependency principle, the flow of processing and the direction of dependency must be reversed.
The technique for solving this problem is called dependency inversion.
As the name suggests, this technique is used to satisfy the Dependency Inversion Principle (DIP).
So how do we reverse the dependency?
In this chapter, we introduce a technique called Dependency Injection (DI), which is commonly used to reverse dependencies.

DI library for TypeScript

Dependency Injection is a technique that has been used for a long time in statically typed languages such as Java.
You can build your own mechanism to realize DI, or you can use existing DI libraries (DI frameworks).
For example, in Java, there are many DI libraries such as Spring Framework and google/guice.
These DI libraries allow you to use DI for developing various applications.

How about in the context of JavaScript and TypeScript?
It may not be common to use DI in web frontend development.
Nevertheless, there are DI libraries available for JavaScript and TypeScript.
For example, AngularJS and Angular have a DI framework built in.
There are also libraries that provide DI functionality on its own, such as InversifyJS and TSyringe.
Both InversifyJS and TSyringe are DI libraries for use with TypeScript.
InversifyJS is a library with over 5000 Github stars and is used in over 18,000 repositories.
On the other hand, there doesn't seem to be much active development going on these days.
TSyringe is a DI library that is mainly developed by Microsoft. As of September 2020, it has about 1,400 stars on Github, and it seems to be under continuous development.

In this chapter, we will first introduce a simple method to perform DI without using libraries.
This simplified method uses a simple example to show what DI is trying to accomplish and what problems it has.
We will then explain how TSyringe can be used to solve these problems.

Simple DI without libraries

In this section, we will use a simple example to illustrate DI without using libraries.
The goal is to demonstrate an understanding of the overview of DI and the issues involved in DI.
However, as will be explained later, there are some practical problems with the method presented in this section.
In the next section, we will confirm that these problems are solved by DI using the library.

In this section, we will deal with a simple subject as follows.

import Printer from './Printer';

class Document {
  constructor(private content: string) {}

  output() {
    const printer = new Printer();
    printer.print(this.content);
  }
}

export default class Printer {
  constructor() {}

  print(content: string) {
    console.log('Print:', content);
  }
}

Document will output its own content using the output method.
In the code above, the output method uses the class Printer internally.
Printer prints out the received string by the print method.
However, in order to simplify the implementation, we only use console.log for the output.
The codes to use Document are as follows.

import Document from './Document';

const document = new Document('this is sample text');
document.output() // "Print: this is sample text"

Looking at the dependencies, we see a dependency from Document to Printer.
Now let's assume that Email is added as an output of Document.
An example codes for this would look like the following

import Email from './Email';
import Printer from './Printer';

export default class Document {
  constructor(private content: string, private method: Printer | Email) {}

  output() {
    if (this.method instanceof Printer) {
      this.method.print(this.content);
    } else {
      this.method.send(this.content);
    }
  }
}

export default class Email {
  constructor() {}

  send(content: string) {
    console.log('Email:', content);
  }
}

New Email has been added, and Document now receives the output method in the constructor.
The dependency in this implementation is still the same as before, from Document to Printer.
In addition, Document now also depends on Email.
The code for the user side looks like this.

import Document from './Document';
import Printer from './Printer';
import Email from './Email';

const printerDocument = new Document('this is sample text', new Printer());
printerDocument.output(); // "Print: this is sample text"

const emailDocument = new Document('this is sample text', new Email());
emailDocument.output(); // "Email: this is sample text"

As you may have already noticed, this implementation violates the DIP.
This is because Document depends on the concrete implementations Printer and Email.
This means that if Printer or Email is changed, Document will also be affected.
In a simple example, if you rename the print method of Printer, you will need to modify the output method of Document too.
Also, if you want to add more output methods for Document, as you did for Email, you need to modify Document.
This is a violation of the Open-Closed Principle (OCP): "open to extensions".
To solve the above problems, we will use DI to reverse the dependencies.
Reverse the dependency in the following steps.

Create Document interface on DocumentOutputMethod side
Printer and Email implement the DocumentOutputMethod interface
Document implements the process using the interface
Pass an instance of the class that implements the DocumentOutputMethod interface to the constructor of Document in the user side codes

This is called Dependency Injection (DI) because the instance to be depended on in step 4 is injected from the outside.
Let's take a look at an example implementation.

export interface DocumentOutputMethod {
  output: (content: string) => void;
}

export default class Document {
  constructor(private content: string, private method: DocumentOutputMethod) {}

  output() {
    this.method.output(this.content);
  }
}

Added the DocumentOutputMethod interface under the management of Document.
And Document uses this DocumentOutputMethod to implement the output method.
By doing this, you can see that it no longer depends on specific implementations such as Printer or Email.

import { DocumentOutputMethod } from './Document';

export default class Printer implements DocumentOutputMethod {
  constructor() {}

  print(content: string) {
    console.log('Print:', content);
  }

  output(content: string) {
    this.print(content);
  }
}

import { DocumentOutputMethod } from './Document';

export default class Email implements DocumentOutputMethod {
  constructor() {}

  send(content: string) {
    console.log('Email:', content);
  }

  output(content: string) {
    this.send(content);
  }
}

Printer and Email implement the DocumentOutputMethod interface.
Added output method to satisfy the DocumentOutputMethod interface.
This means that Printer and Email now depend on Document.
The above fix reversed the dependency.

import Document from './Document';
import Printer from './Printer';
import Email from './Email';

const printerDocument = new Document(
  'this is sample text',
  new Printer()
);
printerDocument.output();

const emailDocument = new Document('this is sample text', new Email());
emailDocument.output()

Finally, in the code of the user side, the constructor of Document is passed an instance of a class that implements the DocumentOutputMethod interface.
Now you can do DI without using the library.

Problems with this method

Actually, there is a problem with this method.
That is, when you instantiate Document, you need to instantiate and pass in Printer and Email.
This is another way of saying that any code that uses Document will always depend on Printer and Email.
In the above example, main.ts is affected by this, but
If you use Document in multiple locations, each location will depend on Printer and Email.
After removing the dependency on the concrete implementation from Document, this just shifts the dependency elsewhere.
To solve this problem, the dependency on concrete code should be gathered in as few places as possible, as described in Introduction to Clean Architecture for TypeScript: PART4.

So how do we aggregate our dependency on concrete code?
This can be solved by using an object called a DI container, which has a correspondence table of dependencies.
The DI container holds a list of correspondences between the class to be injected (Document in this case) and the class to inject (Printer or Email).
When instantiating the class to be injected, it automatically selects the class to inject from the correspondence table of the DI container, instantiates it, and passes it on.
Then, the description of the correspondence of the DI containers is integrated into the main component or configuration files.
In this way, the class to be injected (Document) can be used in various places while consolidating the dependencies on concrete code.

It is of course possible to implement a DI container without any libraries.
However, there are a number of technical issues that need to be resolved, and it is quite difficult to implement them on your own.
This is a brief bullet list of issues that need to be resolved.
If you are interested, please check out the details.

Need to use decorator
Metadata needs to be retrieved by reflection
TypeScript interface information is removed at compile time and cannot be mapped in the DI container.

These points have been resolved in the existing DI library.
In the next section, we will show an example of a DI that solves this problem by using TSyringe.

TSyringe

TSyringe is a DI library developed under the leadership of Microsoft.
As the name suggests, TSyringe allows you to introduce DI into your TypeScript development.

TypeScript Decorators

TSyringe uses an experimental feature in TypeScript called Decorators.
Decorators are in the Stage 2 Draft stage of JavaScript as of March 2021.
As such, there is room for change as a specification.
Similarly, TypeScript has been implemented it as an experimental feature, and its specifications are subject to change in the future.

So why does TSyringe use Decorators?
This is because the nature of the DI library is such that it works well with decorators (as a general language feature).
The DI library needs to know in some way the class to which it is injecting dependencies.
Before decorators were used, the injection target was set by a configuration file.
In this way, it is not possible to know what the DI settings are in the file where the class is declared.
There is also the cost of writing and managing configuration files.
By using decorators, these problems can be solved.
The following is an example of using TypeScript Decorators (not related to TSyringe).

function methodDecorator(target: any, props: string, descriptor: PropertyDescriptor) {
  console.log('This is method decorator f()');
}

function classDecorator(constructor: Function) {
  console.log('This is class decorator f()');
}

@classDecorator
class SampleClass {
    @methodDecorator
    hoge() {
        return null;
    }
}

In order to use Decorators in TypeScript, you need to add the following setting in the compiler options.

  {
    "compilerOptions": {
      "experimentalDecorators": true
    }
  }

Installation and initial setup

This section describes the setup for using TSyringe.
The information here is based on official documentation.
First, install the package.

Install the package tsyringe by

$ npm install --save tsyringe

or,

$ yarn add tsyringe

TSyringe uses an experimental feature called Decorators in TypeScript, so we will rewrite tsconfig.js as follows

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

We can use Decorators by enabling experimentalDecorators.
You can also enable emitDecoratorMetadata to allow the decorator to handle a lot of metadata.
To enable the Reflect API to handle metadata, you need to select one of the following libraries to use as a polyfill.

reflect-metadata
core-js (core-js/es7/reflect)
reflection

In this example, we install reflect-metadata as shown below,

$ npm install --save reflect-metadata

or,

$ yarn add reflect-metadata

reflect-metadata needs to be import only once before using DI.
It is a good idea to do import at the top level as much as possible.

import "reflect-metadata";

Now you are ready to use TSyringe.
Next, let's look at how to actually do DI.

Define the class where you want to do DI

TSyringe provides a simple API for doing DI.
The implementation code differs depending on whether interface is used for the type of the object to be injected or not.
Here is an example of how to use interface.
For more information, please refer to the official documentation.

First, define the type to be injected with interface.

// apiInterface.ts
export interface User {
  id: number;
  name: string;
}

export interface UserApiInterface {
  fetchUser: (args: { id: number }) => User;
}

UserApiInterface defines an API for retrieving user information.
It is assumed that the class that implements this interface includes processes such as communicating with the API server and connecting directly to the DB.
In the following, as a mock, we will implement a class that receives a user ID and returns static information.

// apiImpl.ts
import { UserApiInterface, User } from './apiInterface';

export class UserApiImpl implements UserApiInterface {
  fetchUser({ id }: { id: number }): User {
    return {
      id,
      name: `This is fetchUse of UserApi: ${id}`.
    };
  }
}

Then, define the class in which UserApiInterface should be injected.

// api.ts
import { injectable, inject } from 'tsyringe';

import { UserApiInterface } from './apiInterface';

@injectable()
export class UserApi {
  constructor(
    @inject('UserApiInterface') private api: UserApiInterface
  ) {}

  fetchUser(args: { id: number }) {
    return this.api.fetchUser(args);
  }
}

UserApi receives an object of type UserApiInterface in constructor as an argument and keeps it as a private member.
Then, in UserApi.fetchUser(), it calls api.fetchUser(), which is implemented in api.
In this way, UserApi can change its behavior depending on the object passed in constructor.
By writing @inject('UserApiInterface') in constructor, we pass the interface metadata to the DI library side.

Injecting an object

Now, inject the object into UserApi.

// main.ts
import { container } from 'tsyringe';

import { UseApiImpl } from './apiImpl';
import { UserApi } from './api';

container.register('UserApiInterface', {
  useClass: UserApiImpl
});

const userApi = container.resolve(UserApi);

container is TSyringe's DI container, which holds the information to perform DI.
This container's register() method sets the object to be injected.
In this example, we are configuring UserApiInterface to inject UserApiImpl.
And finally, container.resolve(UseApi) instantiates UserApi.
At this time, container instantiates UserApiImpl and passes it to UserApi.

In other words, TSyringe is a mechanism to create instances while resolving dependencies (which registered by register()) by resolve().

This is the basic usage of TSyringe.
This DI mechanism can be used to reverse the dependency.

Dependency Inversion with DI Library

In the previous section, we presented an example of DI using TSyringe.
As many readers may have noticed from the implementation examples, using a DI library like TSyringe does not automatically reverse the dependencies.
The DI library does this by externally selecting and injecting the objects that a class depends on.
Therefore, it is possible to reverse the dependency by using it properly, but on the other hand, it is not possible to change the direction of the dependency if it is not used properly.
This section describes how to use the DI library to reverse the dependencies.

Design modules

First, let's design modules that will be the subject of our example.
In this section, we will consider the User model, which is the domain model, and Database, which is responsible for persisting the model.
User corresponds to the business logic and is located at the center of the concentric circles diagram.
And since Dataset is a concrete module, it is located outside the concentric diagram.
Therefore, in accordance with Clean Architecture, the dependency goes from Database to User.
This is represented in the diagram as the above image.
Database can know about User, but conversely, User cannot know about Database.
For the sake of illustration, let's assume that one file corresponds to one module, and create user.ts and database.ts.

First, let's define each one without considering the correct dependencies.

import Database from './database';

export default class User {
  private _id: number | null;

  private _name: string;

  constructor(private database: Database) {
    this._id = null;
    this._name = '';
  }

  set id(value: number) {
    this._id = value;
  }

  set name(value: string) {
    this._name = value;
  }

  get name() {
    return this._name;
  }

  save() {
    if (typeof this._id === 'number') {
      this.database.save(this);
    }
  }
}

User can be set to id and name.
It persists itself via Database by User.save().

import User from './user';

export default class Database {
  save(user: User) {
    console.log(`${user.name} has been saved`);
  }
}

Database will receive the User model and persist it.
However, for the sake of simplicity, we will only display the received User's name in the console.

Let's take a look at the dependency between User and Database defined so far.
Database is import the type information of User.
User also uses Database as import, but
This is because User uses Database for persistence.
If you look at these dependencies, you can see that they violate the dependency rules.

Now, let's fix the dependency to the correct orientation.

Reversing dependencies between modules

First, define DatabaseInterface in user.ts.

export default class User {
  private _id: number | null;

  private _name: string;

  constructor(private database: DatabaseInterface) {
    this._id = null;
    this._name = '';
  }

  set id(value: number) {
    this._id = value;
  }

  set name(value: string) {
    this._name = value;
  }

  get name() {
    return this._name;
  }

  save() {
    if (typeof this._id === 'number') {
      this.database.save(this)
    }
  }
}

export interface DatabaseInterface {
  save: (user: User) => void;
}

Change the constructor argument of User to DatabaseInterface.
This will remove import from user.ts to database.ts.
User is no longer dependent on Database.
Next, modify Database so that it implements DatabaseInterface.

import User, { DatabaseInterface } from './user';

export default class Database implements DatabaseInterface {
  save(user: User) {
    console.log(`${user.name} has been saved`);
  }
}

Database is importing User, which turns out to be fine according to the dependency rules we were aiming for.
Now we have satisfied the dependency rule.
The last step is to configure TSyringe.

import { injectable, inject } from 'tsyringe';

@injectable()
export default class User {
  private _id: number | null = null;

  private _name: string = '';

  constructor(
    @inject('DatabaseInterface')
    private database: DatabaseInterface
  ) {}

  set id(value: number) {
    this._id = value;
  }

  set name(value: string) {
    this._name = value;
  }

  get name() {
    return this._name;
  }

  save() {
    if (typeof this._id === 'number') {
      this.database.save(this);
    }
  }
}

$export interface DatabaseInterface {
  save: (user: User) => void;
}

Added User with @injectable() and added database argument of constructor with the decorator @inject('DatabaseInterface').
Now you can inject Database into User by container.
Let's take a look at the code that uses these modules.

import { container } from 'tsyringe';
import User from './di/user';
import Database from './di/database';

container.register('DatabaseInterface', {
  useClass: Database
});

export const user = container.resolve(User);

user.id = 0;
user.name = 'test user';
user.save(); // 'test user saved' will be displayed in the console

This reversed the dependency and helped us to follow the rules.
The important thing here is to define DatabaseInterface , on which User originally depends, in the User module.
In this way, User can manage DatabaseInterface within the scope of its own responsibilities without directly relying on Database.
In other words, if you define DatabaseInterface in the Database module, it will lose its meaning.

Now we know that with proper use of interfaces and DI, we can reverse the dependencies between modules.

Aggregating dependencies on concrete code

As described in the previous section, DI without libraries has a problem that it cannot aggregate dependencies on concrete code.
In the example in this section using TSyringe, we can aggregate container.register() into app.ts.
And by using container.resolve(User), the code on the side using User no longer depends on Database.
In this way, we can see that the problem that the simple DI without the library has been solved.

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.

Introduction to Clean Architecture for TypeScript: PART4

Imamori Daichi — Sun, 12 Sep 2021 02:17:19 +0000

Refs

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.

Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education.

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.

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.

Introduction to Clean Architecture for TypeScript: PART3

Imamori Daichi — Sun, 12 Sep 2021 02:09:17 +0000

Refs

Component Principles

This section describes the component-level design principles.
As mentioned earlier, SOLID is a design principle for connections between modules.
In Clean Architecture, a component is a set of modules, which is the unit of deployment.
In other words, a component is a collection of modules designed based on SOLID.
The component principles described in this section guide how to design components.
Some of the principles of the component are similar to SOLID.
This suggests that the main ideas of these principles can be applied recursively regardless of the size of the component.

What is a component?

Components are the units of deployment.
They are the smallest entities that can be deployed as part of a system.
In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs.
In compiled languages, they are aggregations of binary files.
In interpreted languages, they are aggregations of source files.
In all languages, they are the granule of deployment.
(Robert C, Martin. "Components". Clean Architecture. Pearson Education.)

In TypeScript, for example, each package managed by npm is a deployment unit and a component.
Web Components, as the name implies, are also components.
What is difficult to determine is what is a component in an application development.
If you divide the compilation granularity appropriately into jar files as in a Java application, they become components.
On the other hand, TypeScript applications are usually transpiled as a whole.
In other words, an application is a single deployment unit.
Of course, we may break it up into chunks to optimize delivery, but that is more to reduce the load on the client side rather than to reduce the granularity of build and deployment.
With this background, it will be difficult to adopt the "component = deployment unit" approach as is.
On the other hand, this doesn't mean that the component principle is useless for designing React applications.
For example, in developing an application, processes that are highly reusable may be separated as libraries.
When this happens, it means that the library is recognized as a separate component from the application.
Have you ever made a library without being sure, because "it's highly reusable" or "it looks better as a library"?
By knowing these principles, you will be able to determine how components should be made independent from the application.

Reuse/Release Equivalence Principle (REP)

The granule of reuse is the granule of release.
(Robert C, Martin. "Component Cohesion". Clean Architecture. Pearson Education.)

The Reuse/Release Equivalence Principle (REP), as the name implies, is the principle that granule of reuse and granule of release should be equivalent.
As an example, consider the reuse of a component A. Suppose that the desired function cannot be reused without another component B.
In this case, the unit of reuse and the unit of release are different.This is an example of "unit of reuse < unit of release".
On the other hand, if "unit of reuse > unit of release", then a single release unit contains multiple granule of reuse.
In this case, if you modify only one reuse unit, you will also need to release it.
From the above, by making the unit of reuse and the unit of release equivalent, the cohesion of components can be improved.

Common Closure Principle (CCP)

Gather into components those classes that change for the same reasons and at the same times.
Separate into different components those classes that change at different times and for different reasons.
(Robert C, Martin. "Component Cohesion". Clean Architecture. Pearson Education.)

The Common Core Principle of Closure (CCP) is a component version of the Single Responsibility Principle (SRP).
What the two principles have in common is that one element should not be changed for more than one reason.
In the case of SRP, an element is a class, and in the case of CCP, it is a component.

CCP is also closely related to the Open-Closed Principle (OCP).
The "closed" in OCP meant closed to modification.
CCP will change this wording to "combine similar types of changes into one component" to achieve the same goal.
We aim to achieve the same goal.

When you want to cut out a library from your application, you need to pay attention to when that library is going to be modified.
For example, if you want to cut out common UI components to be used in multiple applications, be careful that these UI components are really changed for different reasons than the application.
You also need to pay attention to whether that each element of cut out UI component will be modified for the same reason.
This is because elements that change for different reasons need to be separated into different components.

Common Reuse Principle (CRP)

Don't force users of a component to depend on things they don't need.
(Robert C, Martin. "Component Cohesion". Clean Architecture. Pearson Education.)

The Common Reuse Principle (CRP) is a principle for determining which elements should be combined into components in the same way as CCP.
While CPP focuses on the reason for the change, CRP focuses on the user's usage.

It is also a generalization of Interface Separation Principle (ISP) to components.
What CRP and ISP have in common is that users should not rely on what users do not use.

CRP can help you determine not only which elements should be included in a component, but also which elements should not be included.
By assuming the user who will use the component, we can ensure that the component does not contain elements that will not be used by that user.

In general, I think there are multiple possible use cases for a component.
For example, there are libraries for date manipulation such as Moment.js.
This library is divided into two components: Moment and Moment Timezone.
This is because there are two use cases where you want to perform date manipulations: one where you want to take timezone into account, and one where you do not.
If we follow the CRP approach, we should avoid forcing users who do not need timezone handling to rely on the timezone module.
In other words, assuming that the use case of not using timezone is not negligible, this kind of component division in Moment.js satisfies the CRP.

Acyclic Dependencies Principle (ADP)

Allow no cycles in the component dependency graph.
(Robert C, Martin. "Component Coupling". Clean Architecture. Pearson Education.)

Acyclic Dependency Principle (ADP), as the name implies, calls for dependencies to be acyclic.
In TypeScript, it can be detected by eslint rule import/no-cycle.
It is easy to imagine that the cycle of dependency can lead to many unexpected problems.
For example, if class A and class B depend on each other, it is easy to detect and imagine the possible problems.
In an extreme case, if class A and class B instantiate each other in the constructor, the process will loop.
A little more confusing is the case of indirect circular dependence. In this case, the problem is that a modification of one side indirectly affects the other.
Suppose that class C and class D are indirectly circularly dependent on each other. Then, changes to class C will have some effect on class D.
Then class D will be modified to accommodate the changes in class C.
In this case, class C also depends on class D, so class C is also affected by the modification of class D.
This is even though the modifications to class D were intended to address changes in class C.
Thus, the cyclic of dependencies means that the effects on change are cyclic.
For products with larger applications and more developers, these issues can be hard to ignore.

In order to solve the circular dependency, we need to rethink the division of components.
Specifically, we will cut out the elements that class C and class D have in common and make them into new components.

Stable Dependencies Principle (SDP)

Depend in the direction of stability.
(Robert C, Martin. "Component Coupling". Clean Architecture. Pearson Education.)

Stable Dependency Principle (SDP) defines the relationship between dependency and stability.
As explained in SOLID's Dependency Inversion Principle (DIP), code stability and dependency direction are closely related.
SDP gives the details of the relation.

Stability

So how is the stability level determined?
In Clean Architecture, stability is defined as "something that cannot be easily moved".
A component that is "hard to change" is said to be a stable component.
In other words, it is dependent on many components.
This is because if you change a component that is dependent on many other components, it will affect many other components and they will need to be adjusted.
The number of dependencies from other components determines the stability of that component.
If you want a component to be stable, design it to be dependent on other components.
On the other hand, components that are expected to change a lot need to be easy to modify, and thus need to be unstable.
To make a component unstable, make it as independent from other components as possible.

In "Clean Architecture", a quantitative measure of stability is presented.
If you are interested in this topic, please refer to "Clean Architecture".

Stable Abstractions Principle (SAP)

A component should be as abstract as it is stable.
(Robert C, Martin. "Component Coupling". Clean Architecture. Pearson Education.)

Stable Abstractions Principle (SAP) specifies the relationship between stability and abstraction.
In the previous section, we explained that stability can be specified by dependencies.
And SAP says that the level of abstraction must be determined by the level of stability.
So why does a highly stable component also need to be highly abstract?
As an example, let's look at the business domain.
Your business domain is the core element of your business, and you want it to be stable.
Therefore, it should be designed to be dependent on other components to ensure a high degree of stability.
But then, the high stability of the business domain makes it difficult to fix.
This makes the business inflexible, and the architecture becomes a bottleneck for the business.
So, to make it easier to make changes while maintaining a high level of stability, we use a high level of abstraction.
Design the business logic to a high level of abstraction through interfaces and abstract classes, and make other components depend on these.
This way, modifying the business logic within that level of abstraction will not affect other components.

SDP + SAP = DIP

Stable Dependency Principle (SDP) says, "Depend on the less stable to the more stable".
Stable Abstractions Principle (SAP) says, "If something is less stable, make it less abstract. If it is more stable, make it more abstract".
Putting these two principles together, we can say, "Depend on the lower level of abstraction to the higher level".
This is exactly what Dependency Inversion Principle (DIP) is.
Of course, DIP is a module-level principle, while SDP and SAP are component-level principles, so strictly speaking, they cannot be put together.
However, through the explanations I have given so far, I think the relationship between these three principles has become clearer.

NEXT: Introduction to Clean Architecture for TypeScript: PART4.

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.

Introduction to Clean Architecture for TypeScript: PART2

Imamori Daichi — Sun, 12 Sep 2021 02:02:36 +0000

Refs

Design principles

In the book "Clean Architecture", before moving on to the discussion of architecture, there is an explanation of a design principle called SOLID.
SOLID principles are a set of principles that apply at the module level and provide guidance for connections between modules.
Although the design guidelines for the code level, which is the building block of a module, are not covered in this book, "Clean Code" by Uncle Bob or "The Art of Readable Code" may be helpful.
Adherence to the SOLID principles is a key element in achieving Clean Architecture.
In this book, we will also look back at the content of SOLID before discussing Clean Architecture in React applications.
SOLID is an acronym for the following five principles

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

In Clean Architecture, the SOLID principle is introduced as having the following three objectives

Be resistant to change.
Easy to understand.
Be available for use in many software systems as a basis for components.

"Easy to understand" is a characteristic that is also required at the code level.
Then, by connecting modules that consist of well-written and clean code based on SOLID, the relationship between modules becomes easy to understand.

At first glance, "Be available for use in many software systems" tends to be used in situations where many users will use it, such as libraries and frameworks, but it can also be important in designing specific software.
As your business succeeds and your software grows, you will increasingly want to make certain modules available to other systems within your business.
For example, a service that was initially intended only for the web, but later grew to require native app development.
If you want to use some modules of your software written in React from React Native, you can minimize the modification for reuse if the SOLID is satisfied beforehand.

And "Be resistant to change" is a key feature in carrying out the objective of protecting the business domain from changes in other components.
In particular, the Dependency Inversion Principle (DIP) plays an important role in protecting the business domain from dependencies.
Let me introduce the five principles of SOLID in turn.

Single Responsibility Principle (SRP)

A module should have one, and only one, reason to change.
(Robert C, Martin. "SRP: The Single Responsibility Principle". Clean Architecture. Pearson Education.)

The term "actors" refers to a grouping of users and stakeholders.
For example, let's take an e-commerce service as an example.The following actors may be considered.

Users who shopping
Users on the store side who manage the products
Stakeholders who determine the commission to the store side
The team that decides on the sale launch

For these actors, make sure that one module depends on one actor.
In other words, SRP is the principle that no module should be affected by more than one actor.
The DRY (Don't repeat yourself) principle should also be considered when applying SRP.
I won't go into the details of the DRY principle itself, but in a nutshell, it is the principle that code that does the same thing should be put in one place.
If you try to practice DRY easily, you will end up sharing the same process of doing the same thing.

If you make processes that have responsibilities for different actors common because they are doing similar things, you may have trouble later on.
This is because even if they seem to be doing the same thing at the moment, as long as the actors they depend on are different, it may be necessary to add different actor-dependent processes in subsequent updates.
In other words, you may end up merging seemingly identical but essentially different processes.
You can distinguish such cases by identifying which actor the process depends on.
Of course, even if the actors are different, the process can be common if there is a relationship between them.
In any case, when practicing DRY, it is necessary to consider the SRP as well and make a careful decision.

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) was proposed by Bertrand Meyer in 1988.

A software artifact should be open for extension but closed for modification.
(Bertrand Meyer. Object Oriented Software Construction, Prentice Hall, 1988, p. 23.)

It must be open for extensions such as adding features.
"open" means that it can be added without affecting the existing code.
And when modifying the existing code of a module, the effect of the modification must be closed within the module.
The OCP defines these two rules.

What are the situations in which this principle is not being followed?
Even if you want to add a trivial feature, you will need to modify the existing code.
When adding a new feature, we carefully read the dependencies among the thousands or tens of thousands of existing lines of code and make modifications.
The larger the code base, the more man-hours it takes to add features, even if it is a trivial feature.
On the other hand, if you follow OCP, you can limit the impact of specification changes and bug fixes because the modifications are closed to the module.

Being open to extensions and closed to modifications makes the software resistant to feature additions and specification changes.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) was proposed by Barbara Liskov in 1988.

What is wanted here is something like the following substitution property:
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.1
(Barbara Liskov, "Data Abstraction and Hierarchy," SIGPLAN Notices 23, 5 (May 1988).)

In other words, "If S is a derivative of T, then it must behave the same even if T is replaced by S.
Since it is difficult to explain with just words, here is an example code.
This can be expressed in TypeScript as follows.

interface T {
 value: number;
}
interface S extends T {}
const o1: S = { value: 1 };
const o2: T = { value: 2 };
const P = (arg: T) => arg.value;
P(o2);
P(o1);

Here, for the sake of illustration, we have assumed that T is a simple type with only value. In fact, what details T has has nothing to do with LSP.
S inherits from T.
The function P takes T as an argument.
In this case, since o2 is type T, so P(o2) is accepted.
Similarly, o1, which is type S, P(o1) is also accepted.
In such a case, we say that S is a derived type of T.
In other words, the LSP says that if you want to inherit a type, it should be a derived type.

Looking at this example alone, one might think, "What is this, just inheritance of types, or is LSP just a rephrasing of the language feature of inheritance?
To show that this is wrong, here is an example of inheritance that violates the LSP.

class Rectangle {
  set width(w: number) {
    this.width = w;
  }
  set height(h: number) {
    this.height = h;
  }
  calcArea(): number {
    return this.width * this.height;
  }
}

class Square extends Rectangle {
  set width(w: number) {
    this.width = w;
    this.height = w;
  }
  set height(h: number) {
    this.width = h;
    this.height = h;
  }
}

const o1 = new Square();
const o2 = new Rectangle();
// Function to find the ratio of the sum of the lengths of the sides to the area
const P = (arg: Rectangle, width, height) => {
  arg.width = width;
  arg.height = height;
  return (width * 2 + height * 2) / arg.calcArea();
};
P(o2, 2, 5); // Can be calculated correctly
P(o1, 2, 5); // 5 * 4 / 5 * 5 is correct, but actually (2 * 2 + 5 * 2) / 5 * 5 is calculated

In this codes, we use the Rectangle type to represent a rectangle and the Square type to represent a square as examples.
This is an example of an old known LSP violation.
Mathematically, according to the definition, a square is a special case of a rectangle, so it might seem natural that Square inherits from Rectangle.
However, a square assumes tighter constraints than a rectangle. It is the constraint that the length of the vertical side is equal to the length of the horizontal side.
Therefore, in Square, when setting the length of the edge, the length of the vertical and horizontal edges are processed to be the same.
As a result, P(o1, 2, 5) is getting a different result than intended.

If there is codes that violates the LSP like this, conditional branching will occur on the client side that uses it (in this case, the function P()).
Then, when there are more classes inheriting from T, it becomes necessary to modify the conditional branch on the client side.
This means that it also violates the Open-Closed Principle (OCP).

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) can be summed up: You should not cram everything into a single interface, but
provide only the functionality that the client needs.

This is also related to SRP.
Consider the following example of an EC site with the following actors.

Buyer: The user who purchases the product
Seller: The user who sells the product

Then, these two users are abstracted by a single interface User.
User requests the methods getPurchaseHistory() and getTotalSales(), but the former method is only used by Buyer, while the latter is only required by Seller.
At this time, the implementation of Buyer will need to implement some processing, even though it does not use getTotalSales().
To begin with, Buyer did not need to know about the existence of getTotalSales(), but by violating ISP, it created an unnecessary dependency.
User also violates SRP because it depends on two actors.
Using or modifying User will require changes to both Buyer and Seller, which may also violate OCP.

Being careful not to overburden any one interface according to the ISP will also help to protect other principles such as SRP and OCP.

interface User {
  id: string;
  name: string;
  getPurchaseHistory: () => Purchase[]; // get the purchase history
  getTotalSales: () => number; // get total sales
}

class Buyer implements User {
  constructor(public id: string, public name: string) { }
  getPurchaseHistory() {
    const history = …; // Process to retrieve purchase history
    return history;
  }
  getTotalSales() {
    return 0;
  }
}

class Seller implements User {
  constructor(public id: string, public name: string) { }
  getPurchaseHistory() {
    return [];
  }
  getTotalSales() {
    const sales = …; // Process to calculate total sales
    return sales;
  }
}

Dependency Inversion Principle (DIP)

The last part of SOLD is Dependency Inversion Principle (DIP).

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.
(Robert C, Martin. "DIP: The Dependency Inversion Principle". Clean Architecture. Pearson Education.)

What is the source code dependencies?
In the case of TypeScript, a dependency is created by referencing import or require.
In other words, the DIP says that when referring to import, you should specify an abstract code such as interface, not a concrete implementation code.

For example, suppose that a.ts imports b.ts.
At this time, a.ts will know the file name of b.ts as well as the classes and methods described in it.
And if b.ts is changed, it will also affect a.ts.
This is even if a.ts is originally a stable code that is not easily changed.

stability of the code

This is where the idea of "stable code" comes into play.
Suppose all the codes could be divided into "stable codes" and "unstable codes".Then, the dependencies can be classified into four types as follows

stable → stable
stable → unstable
unstable → stable
unstable → unstable

Think of the left side of the arrow as being dependent on the right side.
The first is not a problem because both sides are stable.
In 2, the stable code depends on the unstable code, and the inherent stability is compromised.
3 does not cause problems because the unstable code depends on the stable code.
In 4, the unstable code depends on the unstable code, which makes it more unstable, but it is not as much of a problem as 2.
In other words, we need to eliminate the relationship in 2 and reduce the relationship in 4 as much as possible.

So what exactly are "stable code" and "unstable code"?
In Clean Architecture, we focus on the following two points when considering stability.

abstract or concrete
close to input/output or close to domain model

Abstract or concrete?

Hidden in the DIP is the assumption that abstract components are stable and concrete components are unstable.
In order to verify whether this assumption is correct, let's compare the abstract interface with its concrete implementation.
As the interface is modified, the implementation is modified accordingly.
On the other hand, the interface does not necessarily need to be changed when the implementation is changed.
This shows that the abstracted code is more stable.
It can be said that abstraction is the process of extracting the common denominator or essence from multiple concrete objects. Therefore, it is easy to understand that abstracted code is hard to be changed.
However, it is important to note that implementation is not always easy to change.
For example, the standard library of a programming language is an implementation, but it does not change much.
There is no need to be more nervous than necessary about references to such an unchanging implementation.

Thus, abstract or concrete is an important indicator for the stability of a code.
On the other hand, concrete codes are not necessarily changeable.
In addition, please keep in mind that not all codes can be divided into stable or unstable, and that there are varying degrees of stability there.

Close to input/output or close to domain model

As briefly introduced in the first image of this article, Clean Architecture divides the software into layers of concentric circles.
The UI View, DB, storage and other inputs and outputs are located on the outermost side, and the domain model is located on the innermost side.
The intention is to place what we want to stabilize inside the layer and protect it from the unstable outside.
We also use DIP to protect the center of the circle, which we want to stabilize.
This concentric circle architecture is the fundamental idea of Clean Architecture.
This is supported by DIP.

Dependency Inversion

According to the DIP, the destination referred to by import must be stable.
But can we always follow this rule?
There are many cases where you want to call unstable code from stable code for processing.
For example, the Clean Architecture considers DB to be the outermost of the concentric circles and unstable.
If you want to operate DB from a stable code inside the circle, you need to operate an unstable code from a stable code.
As you can see, the flow of processing and the direction of dependencies are usually the same. In other words, if you try to manipulate the DB, you will depend on the DB.
However, this would violate the DIP. We need to reverse the process flow and dependencies somehow.
Dependency Injection (DI) solves this problem.
For more information about DI, please refer to the original book for a detailed explanation with sample codes.
DI reverses the flow of processing and dependencies, and protects the domain model at the center of the concentric circles from instability.

NEXT: Introduction to Clean Architecture for TypeScript: PART3.

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.

Introduction to Clean Architecture for TypeScript: PART1

Imamori Daichi — Sun, 12 Sep 2021 01:44:53 +0000

Refs

What is Clean Architecture?

Clean Architecture is a software design methodology proposed by Robert C. Martin.
Looking back at its history, the Clean Architecture methodology was introduced by a blog post on August 13, 2012.
An English version of the book was published in 2017.

Robert C, Martin. "The Clean Architecture". Clean Architecture. Pearson Education.

Clean Architecture is a design methodology derived from Robert C. Martin's experience in various software (or hardware) developments.
The image is often used to represent Clean Architecture, and even if you don't know much about Clean Architecture, you've probably seen this diagram before.
The details of this diagram will be described later, but I introduced it at the beginning because it is an important diagram in explaining the Clean Architecture.
I hope you will keep this concentric circle diagram in mind as you continue reading.
The following sentence is from the preface of Clean Architecture.

The architecture rules are the same!
This is startling because the systems that I have built have all been so radically different.
Why should such different systems all share similar rules of architecture?
My conclusion is that the rules of software architecture are independent of every other variable.
(Robert C, Martin. "Preface". Clean Architecture. Pearson Education.)

These common rules for software development are summarized as practices and are called Clean Architecture.
In other words, Clean Architecture was born as a common rule by highly abstracting the experience gained from various developments.

Of course, extracting best practices from experience and compiling them into rules has been done before Clean Architecture.
The history of programming language paradigms is just that, and so are programming patterns such as the GoF design pattern.
There is also a collection of design principles called SOLID, compiled by Uncle Bob himself.

In "Clean Architecture", Sections I through IV will be used to explain these traditional practices.
In this way, Clean Architecture is a design methodology that draws on existing practices.
Therefore, Clean Architecture is not a design methodology that has been released in recent years, but rather it is based on empirical rules that have been developed by many software developers over the years.
On the other hand, there are some things to keep in mind.As mentioned earlier, Clean Architecture is a highly abstracted method.

Since it does not propose specific implementation methods, it cannot be directly applied to actual software development.
Therefore, it is necessary to understand the meaning of the abstraction of this design methodology and to put it into the concrete work of actual software development.
In some cases, you may want to apply some of the rules in Clean Architecture and ignore others.
However, even if you dare to ignore the rule, there is a big difference between knowing the rule and ignoring it, and breaking the rule without knowing it.
In these articles, we will grasp the principles of Clean Architecture and then discuss how to apply Clean Architecture when building React applications.

Why Clean Architecture?

In "Clean Architecture", the world realized by good software design is described as follows

The goal of software architecture is to minimize the human resources required to build and maintain the required system.
(Robert C, Martin. "What Is Design and Architecture?". Clean Architecture. Pearson Education.)

Leaving aside the question of how feasible this goal is, few developers would deny the goal itself.
Clean Architecture has been proposed as one of the means to achieve this goal.
As I said it is a means to an end, you can also aim for this goal by means other than Clean Architecture.
Of course, not everything will work with Clean Architecture.
The specific implementation is not within the scope of Clean Architecture, and adopting it does not immediately solve anything.
What Clean Architecture provides is the thinking and practices to achieve the above goals.
There is no solid right answer for the implementation to realize it, and there are as many right answers as there are products.

Learn about the background and concept of Clean Architecture, and we believe that cultivating the ability to think about how to apply it to specific implementations is necessary to achieve a step-change in software design.
In particular, it can be applied to React applications to empower not only web development but also application development on multiple platforms and it will support product growth.

Clean Architecture and Domain Driven Design

Domain Driven Design (DDD) is one of the building blocks of Clean Architecture.
DDD is a software design methodology proposed by Eric Evans.
DDD focuses on how to link business domains and software development, and does not refer to individual technologies.
What is important in DDD is that domain experts and software developers, who are familiar with the business domain, can communicate with each other through a common language, the ubiquitous language.
The point is that we shape our services through communication.
Clean Architecture is based on the concept of DDD. Domain models and domain logic, which are formed through communication, are the core and most important elements of a service.
Clean Architecture focuses on how to protect them from surrounding dependencies.

In this way, Clean Architecture is closely related to DDD and cannot be separated from it.
In the book "Clean Architecture", terms such as domain, domain model, and other terms used in DDD such as Entity and Repository also appear.

NEXT: Introduction to Clean Architecture for TypeScript: PART2.

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.

DEV Community: Imamori Daichi

Dependency Injection for TypeScript

Ref

Abstract

DI library for TypeScript

Simple DI without libraries

Problems with this method

TSyringe

TypeScript Decorators

Installation and initial setup

Define the class where you want to do DI

Injecting an object

Dependency Inversion with DI Library

Design modules

Reversing dependencies between modules

Aggregating dependencies on concrete code

Ads

Introduction to Clean Architecture for TypeScript: PART4

Refs

Clean Architecture

Dependency rules

Entity

Use case

Framework

Main component

About the number and naming of layers

Ads

Introduction to Clean Architecture for TypeScript: PART3

Refs

Component Principles

What is a component?

Reuse/Release Equivalence Principle (REP)

Common Closure Principle (CCP)

Common Reuse Principle (CRP)

Acyclic Dependencies Principle (ADP)

Stable Dependencies Principle (SDP)

Stability

Stable Abstractions Principle (SAP)

SDP + SAP = DIP

Ads

Introduction to Clean Architecture for TypeScript: PART2

Refs

Design principles

Single Responsibility Principle (SRP)

Open-Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

stability of the code

Abstract or concrete?

Close to input/output or close to domain model

Dependency Inversion

Ads

Introduction to Clean Architecture for TypeScript: PART1

Refs

What is Clean Architecture?

Why Clean Architecture?

Clean Architecture and Domain Driven Design

Ads