Thank you for the article about clean architecture in Go! :)

I had a question about how you set up the packages (directories) in your project:

Question 1 Was there a specific reason that each repository, usecase, and delivery file was packaged under one directory that matched the model name? Why weren't all the repositories under the same directory and the usecases and delivery files the same? (e.g. go-clean-arch/repositories, go-clean-arch/usecases, go-clean-arch/delivery)

Question 2 Also, why are the models not in the same packages as the repository, usecase, and delivery files?

Example: The repository interface/implementation, delivery, and use-case files for "author” were under go-clean-arch/author, but the author model was in the go-clean-arch/models directory.

NOTE: I'm currently trying to clean up my teams Golang project repo and ensure it's scalable for future development, so I'm wondering if the way you set up this repo had a particular reason. :)

Hello, everyone who reads this and (maybe who also used my proposed architecture in Go).

Thank you very much for the feedback that I received so far. Just to be honest, I'm very new here in the architecting software worlds. So, I'd rather call it folder structure rather than architecture. As we know, software architecture is not just a single application, but a whole business that architected into one or many applications.

Actually, for the current version in the master branch (when I made this PR), nothing wrongs. By far, this project structure solved many cases of my projects.

But, in this recent months, I try several improvements (also with looking at other people's architecture in Go), so now I decide to introduce a domain package.

In my current structure, we will find something like this:

models
├── article.go
├── author.go
└── errors.go 

article
├── delivery
│   └── http
│       ├── article_handler.go
│       └── article_test.go
├── mocks
│   ├── ArticleRepository.go
│   └── ArticleUsecase.go
├── repository //Encapsulated Implementation of Repository Interface
│   ├── mysql_article.go
│   └── mysqlarticle_test.go
├── repository.go // Repository Interface
├── usecase //Encapsulated Implementation of Usecase Interface
│   ├── articleucase_test.go
│   └── artilce_ucase.go
└── usecase.go // Usecase Interface.

So there are will be many packaged module like author, article that contains the implementation and also the contract ArticleUsecase, ArticleRepository, AuthorRepository

So, just out of curiosity, I tried a new improvement that proposed by Ben Johnson here: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 the domain package. But instead of to move it into the root project, I'd rather move it into a single domain, just for the sake consistency with my previous layout that using package models

So in my previous layout, I used models and now I renamed it to domain then move all the interface contract (Usecase and Repository) into this domain package.

So it will be more like this:

domain
├── mocks
│   ├── ArticleRepository.go
│   ├── AuthorRepository.go
│   └── ArticleUsecase.go
├── article.go
├── author.go
└── errors.go 

article
├── delivery
│   └── http
│       ├── article_handler.go
│       └── article_test.go
├── repository //Encapsulated Implementation of Repository Interface
│   └── mysql
│       ├── mysql_article.go
│       └── mysqlarticle_test.go
└── usecase //Encapsulated Implementation of Usecase Interface
    ├── articleucase_test.go
    └── artilce_ucase.go

I don't know yet, is this new layout better than the current layout I used. But, I'll try to use this new layout for my projects. If anything happens, then, this PR will be closed. But if it's good and more comfortable for the developer to use it, then I'll merge this to the branch master. :D

Anyway, if you're a Golang Engineer too, I'd like to hear your opinion about this new proposed layout :D

Hi @bxcodec , thank you for creating this arch. I have a question, should I create multiple repository files to handle multiple tables? For Example I have users and user_addresses tables, and then I create user domain to handle both user and user address. If I have separate Create, Update, Delete function between user and user address, should I create two repository files (user_mysql_repo.go and user_address_mysql_repo.go) or I just create one repository file (user_mysql_repo.go).

Thanks

In this repo, there are building functios like below(NewUsecase or NewRepository)

type mysqlArticleRepository struct {
	Conn *sql.DB
}

// NewMysqlArticleRepository will create an object that represent the article.Repository interface
func NewMysqlArticleRepository(Conn *sql.DB) domain.ArticleRepository {
	return &mysqlArticleRepository{Conn}
}

As you can see, it returns address using &mysqlArticleRepository which of data type is a pointer. So I think return type should be pointer *domain.ArticleRepository like below

type mysqlArticleRepository struct {
	Conn *sql.DB
}

// NewMysqlArticleRepository will create an object that represent the article.Repository interface
func NewMysqlArticleRepository(Conn *sql.DB) *domain.ArticleRepository {
	return &mysqlArticleRepository{Conn}
}

I want to hear what you guys think about this. Thanks for reading this issue. 😄

If I want to replace labstack/echo in this implementation with https://github.com/go-chi/chi Where to put the code and make the change? Don't see any interface around delivery and middlewares.

In domain/article.go we have

type Article struct {
	ID        int64     `json:"id"`
	Title     string    `json:"title" validate:"required"`
	Content   string    `json:"content" validate:"required"`
	Author    Author    `json:"author"`
	UpdatedAt time.Time `json:"updated_at"`
	CreatedAt time.Time `json:"created_at"`
}

Here an Author attribute exists because an Article belongs to an Author

Going from that logic I attempted to add ArticleStats so I made the following changes:

in domain/article.go

type Article struct {
	.
	.
	.
	ArticleStatistics ArticleStats `json:"article_statistics"`
}

and added

in domain/articlestats.go

type ArticleStats struct {
	ID      int64   `json:"id"`
	Article Article `json:"article"`
	.
	.
	.
}

And I get illegal cycle in declaration of Article + illegal cycle in declaration of ArticleStats

How is this solved?

I have read your article and code to help me a lot, but I have a question, do not know how to solve, when a business needs multiple Repository cooperation, and they are a transaction, how to deal with such a situation? And this is the majority of cases, can you add similar examples in the code?

I've been using your go structure for a project I'm working on and I'm hitting a few areas that I'm not quite sure how to solve, at least in a clean architecture way. If we take your directory structure as an example, say we have an http handler for author as well as article. Then say we want to use the same middleware for each handler. How the structure is currently set up is that there's a middleware package within the deliver/http directory for article. Would we have to create the exact same middleware package in author too? Duplicating code is probably not the answer here. Would it be better to create a top level handler/http directory with the middleware in there that can be shared across all entities? How about other utility functions?

Hi I develop more simple clean arch

handlers: any transport layer http web api, grpc, graphql and etc.

app: Business layer

storage: Database and caches

services: external services

https://github.com/Abdukahhor/swe

what do you think ?

First of all, Thank you for your awesome idea 👍

1. In main.go, Is there any reason to name like this? I can't understand the detail feature of this convention with an underscore in front of the package name such as _articleRepo

import (
	_articleHttpDeliver "github.com/bxcodec/go-clean-arch/article/delivery/http"
	_articleRepo "github.com/bxcodec/go-clean-arch/article/repository"
	_articleUcase "github.com/bxcodec/go-clean-arch/article/usecase"
	_authorRepo "github.com/bxcodec/go-clean-arch/author/repository"
)

2. Could I allow to add the package unrelated with models? (indirectly related?) Like below tree, I just define user.go in model and implement authentication feature in auth package. I wanted to separate auth package from user. Actually, I'm not sure with this Idea.

.
├── auth
│   ├── delivery
│   │   └── http
│   └── usecase
├── model
└── user
    ├── delivery
    │   └── http
    ├── repository
    └── usecase

Thank you.

Hi!

I am composing it with reference to this repository in my project and I am very grateful!

Why did you pass context to all layers with the following changes? feat: add context #9

hi @bxcodec thank for your source

i got a lot of help

I want to know why I classified each directory under the domain.

like

article
├── delivery
│   └── http
│       ├── article_handler.go
│       ├── article_test.go
│       └── middleware
│           ├── middleware.go
│           └── middleware_test.go
├── repository
│   ├── helper.go
│   └── mysql
│       ├── mysql_article.go
│       └── mysqlarticle_test.go
└── usecase
    ├── article_ucase.go
    └── article_ucase_test.go

to

article
├── article_handler.go
├── article_test.go
├── article_ucase.go
├── article_ucase_test.go
├── mysql_article.go
└── mysqlarticle_test.go

why i think this needs, when developing have to open many folders

and this sample usefull msa?

Thanks for this repo. I have learnt a lot from it.

I have also tried to modify some of the code to my current knowledge to try to make the whole repository more like a Go project as I know it.

I look forward to discussing some of the relevant changes with you under this PR.

ref: uber-go style guide

Hi I am developing my own website using this project structure. Currently I need to have a logging package and also use of JWT. For the logging package, is it good idea to put its interface inside domain folder and then implement its methods in adaptors layer? And for JWT, I think it doesn't need interface as it is less probable to be ejected. So where to put its codes like GenerateToken and ValidateToken methods? if there be a folder called pkg and then putting JWT there, it will go from inner layer to outer layer however. Could you please help me how to implements tools like jwt and bcrypt. Also where and how to implement a logging feature. Thanks

Thanks a lot for the repo and it is really informative. However I have two small questions about pointer and value for usecase.

1. In this scenario, article usecase is using pointer in both constructor and method receiver, is it because of the repository dependency(sqldb) which is also a pointer?
2. What if I have a simpler usecase which doesn't have dependencies of references, eg: repository and it's just used to do simple stateless calculations without extra pointer dependencies. For these kind of scenarios, may I use copies instead of pointers?

I would be very appreciated if you could clear some of my doubts.

Hello guys,

Would you mind to give some example of basic auth or oauth 2.0 implementation in this architecture? Would really appreciate it 🙏🙏

Many thanks guys!