Directory Setup Questions

[danrix89]

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. :)

[ghostiam]

The answer to the second question: Previously, in version 1, the models were in directories with names, but there were problems with this, golang does not support cyclic imports: https://github.com/bxcodec/go-clean-arch/issues/7

[danrix89]

Since the changes between v1's and v2's packages was that the models were put into a models package. Wouldn't it be helpful to do the same with the repositories, usecases, and delivery files? It seems strange to have those things packaged under separate packages that match the model when the model isn't there either.

I don't think there would be a cyclic package issue by changing the package hierarchy this way.

I apologize if I'm mistaken. I just came from a Java background where we would set up our packages in this way (it was easier to navigate for Java devs).

[bxcodec]

Hi @danrix89

Question 1: No specific reasons, I'm designing it like a module/package by domain, that can be plug-in or plug-out easily later. Let's say I'm working on a monolith project, and this is how I design it. And later if I want to migrate to Microservice, it should be easy as just migrating the package/folder into another service.

And also with this kind of directory structure, if we worked with the team, each person can focus on specific module/package, so it can avoid the unnecessary conflict.

But, feel free to not to follow how the folder structures, but, the idea that needs to understand is, every layer must independent, maintainable, and testable. For example, the Repository layer not tightly coupled to a specific database. And the Delivery not tightly coupled to specific HTTP framework

Question 2: Thanks, @ghostiam for the reply. Like what @ghostiam said, to avoid the cyclic import, and back to answer number 1, I'm trying to stick with my first ideal, like a modular app (should be able to plug-out easily), and I'm trying to find the balance the look and feel from my POV, and it resulting in the V2.

[bxcodec]

Oh yeah, maybe you can take a look a V3 that I'm currently researching.

Currently, on the PR here #21 the differences still only about the folder structures. The concept still the same.

[danrix89]

Thank you for explaining. You've given me a lot of good things to think about. I see now that modularity is key. :)

I don't have anymore question about this, so I'll go ahead and close this issue.