04 Implementing Clean Architecture on Project

At this stage we will try to implement Clean Architecture, where this concept according to Uncle Bob has 4 layers, namely

1. Entities
2. Usecase
3. Controller
4. Framework and Driver

In this project we will make it the same to have 4 layers but there are differences in grouping:

1. Models
2. Repository
3. Usecase
4. Delivery

So this will affect the folder creation structure that will be included in the project. So that friends have an idea, the folder structure is like this.

.
├── cmd
└── main.go
├── models
│ └── article.go
├── repository
│ └── mysql
│ └── article.go
├── usecase
│ └── article
│ └── article.go
├── delivery
│ └── http
│ └── article.go
├── apispec.json
├── docker-compose.yaml
├── go.mod
├── go.sum
└── README.md

Models

This layer is a layer that stores models that will be used in other domains. This layer can be accessed by all layers and by all domains as well. In this project we will create a model that relates to Student data, so the example struct that we will create is like this.

package models

type Student struct {
	ID int64
	NIM string
	Name string
	BirthPlace string
}

Repository

This layer is the layer that will store external related actions, for example in this project we will store data in the database then processes such as querying, inserting, updating and deleting data will be stored here. It should also be noted that there is no business logic in this layer.

This layer’s main task is to determine the datastore that will be used. In this project we choose and use Mysql RDBMS.

If using microserice architecture, then this layer will serve as a link with other services (external) so that this layer is very bound and dependent on the datastore that we use.

Usecase

This layer is the layer in charge of controlling, handling business logic in each domain. This layer will connect between the repository that will be used and even more than one repository can be connected to this layer.

The main task of this layer is to connect the databstore, external data needed by accessing the repository data with the delivery layer. So this layer is fully responsible for the validity of the data, if something invalid occurs in the repository or delivery then this layer must be responsible for handling.

This layer must also contain business logic. For example, counting the total number of articles, data calculation, the process of releasing filtered data where the data is taken from the repository and processed by this layer.

Delivery

This layer is the layer in charge of presenting or being at the forefront of the application, namely output. In this layer, we can also determine what method and delivery will be used using Rest API, HTML, gRPC, File, CRON and others.

Another task of this layer is as a liaison between user and the system. Receive input and validate input according to the standards we have used. For example, in this project we will choose RestFul API as the delivery layer so that communication between the user and the system is done through Rest API.