Re: [Edgex-tsc-core] Delhi -- Cleaner Separation of Internal/External Packages

Steve Osselton
 

Hi Trevor,

This all looks pretty sensible to me.

Cheers Steve.

On 30 June 2018 at 02:41, <Trevor.Conn@...> wrote:

Dell Customer Communication

Hi all – I wanted to send out an email as a heads-up to one of the decisions that came from our last F2F in Palo Alto. This was discussed during the Device Services working group and I wanted to give everyone visibility and an opportunity to comment before changes get made.

 

The Problem

Currently the EdgeX GoLang implementation has no separation between its internal domain model and the models used to pass data out of the system. They are one and the same. Likewise, there is no visibility as to which service client is used by an external application versus solely used internal to the EdgeX platform. This means we are at risk of making changes to either our data models or our service client code that break any applications which have imported those items. We have no way to insulate our consumers from changes we make to the application based on an internal need, nor do we have the ability to hide internal/private details of our data model since our data model is also part of our client contract.

 

The Recommendation

In order to facilitate the separation of internal/external domain models and logic, we realized that we would need to restructure the application packages. At a high level, the changes we decided to make are as follows:

 

/edgex-go/core

·         will be re-purposed to contain those models and libraries which are usable by external applications

·         will include the following:

o   clients package – service clients usable by external applications

o   models package – data models usable by external applications

§  NOTE: These will be identical to the current property bags found today in /edgex-go/core/domain/models

/edgex-go/internal

·         This package will be extended to include all code that we do not want external applications explicitly relying on as recommended by the golang-standards project layout

·         That means the following packages will be moved into here in some fashion

o   /edgex-go/core/command

o   /edgex-go/core/core-data

o   /edgex-go/core/core-metadata

o   /edgex-go/export

o   /edgex-go/support

§  Consul-client, domain, l ogging

§  Service client packages will most likely go to core above

·         Domain models included herein may start off as identical to those found today in /edgex-go/core/domain/models but have the flexibility to change and move around over time according to the internal needs of the platform.

                         

We are looking at making this change early in the Delhi development cycle, so please provide feedback in a timely fashion if you have it. Also please note that any external applications which are directly linking to the current package structure within the master branch of EdgeX will break when we do this. That is unavoidable. We are doing this now so that the pill isn’t too bitter to swallow later.

 

I look forward to your comments.

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 




--
Technical Director
IOTech Systems Ltd.

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