manakuro/golang-clean-architecture

Go with Clean Architecture

golang-clean-architecture

Go with Clean Architecture

Run Docker

$ cd docker
$ docker compose up

Installation

$ make install

Set up database

$ make setup_db

Migrate schema

$ make migrate_schema_up

Seed data

$ make seed

Start server

$ make start

golang-clean-architecture's Issues

Use the interface defined on the internal layer by the external layer.

I'm not a big specialist, but as far as I understand, the essence of clear architecture is to eliminate the dependence of internal layers on external ones. At the same time, the outer layers must implement the abstractions defined on the inner layers.

If this is the case, I don't quite understand why I have to declare the UserRepository interface in golang-clean-architecture/interface/repository/user_repository.go, if the method specification is essentially defined in golang-clean-architecture/usecase/presenter/user_presenter.go.

Probably something like that should be done:

import (
	...
	"golang-clean-architecture/usecase/presenter"
)

...
func NewUserRepository(db *gorm.DB) presenter.UserPresenter {
	return &userRepository{db}
}

Or perhaps you should return the structure.
This will increase the autonomy of the layer's unit - it can be used wherever the signature suits.

However, the first option clearly indicates the direction of dependency.

accessing entitites/models inside interface

Hi i just wanted to know why u accessed models inside the interface layer as clean archi said only outer layer know about the next immediate later aren't we voilating the rule ?

Transaction support

How to do transaction in this approach?

Lets assume I've an usecase which is using 2 repositories and I want transaction between methods of these repositories.

Presenters: Infrastructure leaks into Use Case Layer

Hi @manakuro! First, thank you for this excellent showcase.

I have some concerns about the signature of your use case methods: it includes the return type of your presenter's ResponseUsers method, so there is information from the infra layer leaking to the use case layer.

golang-clean-architecture/usecase/interactor/user_interfactor.go

Lines 22 to 29 in 1c9b1ca

	func (us *userInteractor) Get(u []*model.User) ([]*model.User, error) {
	u, err := us.UserRepository.FindAll(u)
	if err != nil {
	return nil, err
	}
	return us.UserPresenter.ResponseUsers(u), nil
	}

In my case, I'm generating request/response models from an OpenApi file, e.g. I have an api.User type. The presenter should take []*model.User and map it to []*api.User, which requires me to change the signature of the user interactor's Get method (which violates Clean Architecture). Moreover, it is not possible to use the interactor implementation with different presenter implementations.

I think for that reason the return type of use case methods is mostly void in Clean Architecture and presenters take care of writing to the output channel. I'm not sure how to this (in an idiomatic way) in Go.

I would appreciate it if you could share your thoughts on this or correct me :)

should use internal folder instead pkg folder

codes in pkg folder most use like a library .that othe people can import it from it . internal folder is Private application . also I agree with #7 . should use a database interface in repository . even you change database . just add a new database instance and implment the database interface method. anyway nice example.

ref https://github.com/golang-standards/project-layout

Migrations absent

> make migrate_schema 
go run ./cmd/migration/main.go
stat ./cmd/migration/main.go: no such file or directory
make: *** [Makefile:15: migrate_schema] Error 1

I believe you forgot to commit the cmd/migration folder.
Could you send those files, please?
I want to run this to use debug and navigate the calls.
Thank you!

Why does user_repository have a direct dependency on gorm.DB?

In the file interface/repository/user_repository.go, struct userRepository has a direct dependency on gorm.DB which is defined in the outer layer and hence it violates the clean architecture principle.

// interface/repository/user_repository.go
type userRepository struct {
	db *gorm.DB
}

Implementing multiple Controllers

in interface/controller/app_controller.go:

type AppController interface {
	CollectionController
}

on registry/registry.go, we have the following code:

func (r *registry) NewAppController() controller.AppController {
	return r.NewCollectionController()
}

which will be used in main.go to pass down db instance

r := registry.NewRegistry(db)
	e := echo.New()
	e = router.NewRouter(e, r.NewAppController())

and it all works perfectly well, but my problem here is that i'm trying to implement multiple controllers

type AppController interface {
	CollectionController
	DocumentController
}

what modifications needs to be done on *func (r registry) NewAppController() controller.AppController (registry/registry.go) to make it work?