Thanks for the reply! (IMHO):
I understand the "Why", suffering from it everyday! This specific case is not MVC, but a bot. In it's simplest form: New messages come it, and based on user_id, a new agent (goroutine) comes to life, initiated by previous user state and processes the message. As far as I understand, Clean Architecture or 3 Layer architecture or whatever pattern used; all of these patterns are trying to achieve one goal: to implement a one-flow of "Abstractions". One-way flow of abstractions, is enforced in Go (to some extent) by preventing circular imports which produces a compiler error. Yet the layers are hardly coupled by the model. Maybe the best would be going with POGOs (as in POJOs) or getter/setter interfaces (it is discouraged mostly "because JAVA is doing it"). Even in a loosely coupled design (like say messaging all way down to every subsystem/microservice) we still have to deal with data definitions (and versioning!). Also I would like to learn how the fifth Rob Pike's rule of programming (http://users.ece.utexas.edu/~adnan/pike.html) could be applied here? And having all sort of models/payloads (domain models, data models, view models, etc) is too much of a hassle that kills the development process. Still I see this as some sort of inevitable doom we just can contain by writing tests (more tests). But I'm eager to learn if this is possible in a Go idiomatic way - and should we really avoid getter/setter interfaces just because JAVA/C#/etc had done that? I wonder. Thanks again for your answer! I'll watch the video carefully. -- 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.
