Re: Core-Data Refactor Available for Comments

James.White2@...
 

Dell - Internal Use - Confidential

Thanks Drasko. Really good feedback. I'll address with the team on my return from Hannover Messe.
Jim

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Saturday, April 21, 2018 11:11 PM
To: White2, James
Cc: Conn, Trevor; EdgeX-GoLang@...; edgex-tsc-core@...
Subject: Re: [Edgex-golang] Core-Data Refactor Available for Comments

Hi Jim,

On Sat, Apr 21, 2018 at 8:04 PM, <James.White2@...> wrote:
Dell - Internal Use - Confidential

Hi Drasko,
A question for my help and understanding... back in November, we all looked at GoKit and I recall a number of members (including you and Janko if I recall correctly) suggested GoKit came with some complexities that you all felt did not serve the community well (we even noted that in our architectural notes to discourage its use by our community). Trevor did a relook and we can investigate again going forward, but I am curious if you and others in the Go community feel it has made changes (or our project has made enough advancement) that GoKit may be warranted. What are your thoughts now in light of the current direction??
My concerns with go-kit at the time was that newcomers to Go programming would be overwhelmed, because go-kit imposes a certain framework that demands more discipline. However, go-kit actually tries to collect and follow the best architectural practices, and for that reason it must introduce certain conventions.

When I saw that Trevor headed in DDD direction (which I welcome), I realized that it would be potentially beneficial to leverage go-kit, because we started to make architecture more complex anyway (and hopefully now we are all skilled Gophers ;)). This is maybe unavoidable - as soon as we go beyond PoC and start building enterprise product, then subjects of testing, logging and instrumenting become very important.

I proposed re-evaluation of go-kit to avoid potentially reinventing the wheel (i.e. inventing our file structures and similar - practically re-inventing the framework). Mainflux project has been using go-kit for quite some time (even before discussion of it's usage in EdgeX), and for the same reasons that we face now in EdgeX - domain division, logging, instrumenting, etc. And we are also following DDD practice - for example with repositories (will be familiar to Trevor):
https://github.com/mainflux/mainflux/blob/master/manager/manager.go#L14
and aggregates, but also with logging:
https://github.com/mainflux/mainflux/blob/master/manager/api/logging.go
(https://gokit.io/faq/#logging-mdash-how-should-i-aggregate-my-logs)
and metrics: https://github.com/mainflux/mainflux/blob/master/manager/api/metrics.go
(https://gokit.io/faq/#observability-mdash-which-monitoring-systems-are-supported)
that are handled through onion architecture that framework imposes.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Join EdgeX-GoLang@lists.edgexfoundry.org to automatically receive all group messages.