Implement a static-analysis that checks such constraints.
---
For example in file `customer/address.go`
package customer
// category: model
type Address struct {
User user.ID
}
func (address *Address) Update(controller *Controller) { ... }
// alternatively:
var _ = architecture.Model(&Address{})
...
The static analysis tool would parse the "category" or some function that
registers a type.
By parsing the source AST or alternatively walking the structure with
reflection you can derive all the dependencies, e.g.
*> model customer.Address* depends on *model user.ID* and *controller *
*customer.**Controller*
Based on this we can see a violation:
*> model *either directly or indirectly depends on a *controller.*
--
That way you can do pretty extensive tests and checks, whatever you deem
appropriate for your micro-architecture.
Creating separate packages for internal/outer models reduces cohesion...
controller, view, model (and different layers) work quite tightly together,
hence they should be close to each.
Also, recommend reading wrt. MVC:
https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
http://wiki.c2.com/?ModelViewControllerHistory
+ Egon
On Thursday, 6 July 2017 05:06:23 UTC+3, Frederik Creemers wrote:
>
> 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.
