feat: Introduce domain package

[bxcodec]

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

[sananguliyev]

I think this structure is better in terms of the DDD.

[jcorry]

I'd love to see discussion on this from Go architects more experienced than myself.

[zhuharev]

ok

[Anamican]

Looks much cleaner

[Eore]

@jojoarianto actually @bxcodec using named return, so at the end of function, you need to put return
and for pointer afaik is not good using to many pointer, because you will using heap memory instead of stack and will allocated more

[jojoarianto]

Ask: Why not domains (plural)?

[Anamican]

Could you please NOT message in my comments and message directly to the author

[PriteshJain]

Comments here make good read for new people like us, to understand why this way and not the other way. also pull requests are for code review and comments right?

[Anamican]

I agree with that, but thats not my point.
If you scroll down to the end of this page, there is a comment box, what he has done is replied to my comment similar to what you are doing

[PriteshJain]

Ohh I see, missed that in a long page scroll. Very sorry

[bxcodec]

Hi @jojoarianto,

In this PR there are many changes related to pointer just for safer in memory allocation.
There is an explanation about this here https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/

So to summarize, I think, if we really don't need a pointer, we better to avoid it.
It's just a part of the optimization in Golang. If you're not really concern about memory allocation, it's okay to ignore this.

[AlexGrs]

hey ! Curious to know if you did continue with this domain approach or if you revert back to using the previous one (models at the root) with use cases in each sub-packages.

[bxcodec]

Hi @AlexGrs , for microservice I use this.

But for the monolith, I use the previous one, because Monolith will look messier if we organized like this.
I mean the contracts all in one place