I've already asked this question on softwareengineering.stackexchange.com <https://softwareengineering.stackexchange.com/questions/352099/how-to-structure-a-go-application-architected-according-to-the-clean-architectu>, so if you want some reputation points for being helpful, you can answer it there. But in this thread, I'll make my question a little bit more general.
I recently watched a talk by Robert C Martin (Uncle Bob) <https://youtu.be/WpkDN78P884?t=7m8s> where part of the presentation was on how the directory structure of a project should reflect its intent, not its architecture or framework (link goes directly to the relevant timestamp in the video). So for example, the standard layout of a Ruby on Rails app (with app, db, models folders), makes it clear that you're looking at a rails app, but not what that app actually does. Similarly, if your app has a folder for models, views and controllers,, that makes it clear you're building an app using the MVC architecture, but doesn't describe what it does. So to apply this to a Go application for a store, you'd have a "customers" package, a "products" package, an "orders" package and so on. So then the question becomes, how do we structure content within these packages? Let's say we're building our project using the MVC architecture. Then each of our domain-specific packages could contain a models.go, controllers.go and views.go. But then we run into another problem. In an MVC application, the controller should depend on the models and views, but the views shouldn't depend upon the models and vice versa. Import paths make this incredibly visible. If you're in a views package, and you see an import from a models package, you know there's something wrong. In Go, files within a package share a namespace, so while you could inspect the code in views.go to make sure it's not using anything from controllers.go, it's a lot less visible. The option i ended up going for, was to make sub-packages within each domain package. While this works, you soetimes end up having to rename imports because you're relying on models from two domain areas, so you end up doing import ( ordermodels "github.com/username/project/orders/models" customermodels "github.com/username/project/customers/models" ) So is there a better way to achieve both a domain-specific set of top-level packages, and clear dependencies between architecture-specific layers? As you'll see if you read the StackOverflow question, I'm not actually using the MVC architecture, but I think this question applies to any architecture, and MVC is the most widely-used, so I thought it might make my question easier to understand. This question could apply to any architecture where knowing the dependencies between "layers" is important. Best regards, Frederik -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
