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

espy
 

On 7/7/18 6:32 PM, Trevor.Conn@... wrote:

Dell Customer Communication

To continue the thread, I wanted to give visibility to Issue #368. I’ve submitted the first PR against that issue to address the items below and after doing some work, my thinking has shifted a touch. Please see below:

 

I'm about to submit the first PR for this issue in which the majority of the delineated code has been moved to its new location. I'm adding this comment to record my thoughts at this point on what the end goal is going to look like. There will be a couple more subsequent PRs I think.

  • edgex-go/core to be renamed to edgex-go/external
    All code importable by 3rd party applications wishing to integrate with EdgeX will go here
  • edgex-go/core/domain to be removed and models moved up to edgex-go/external/models.
    These models will serve as the data model for external client application consumption
  • edgex-go/core/domain/enums will be collapsed into the above models package
  • Instead of an edgex-go/internal/app directory containing all of the services, I decided to preserve the "core" / "export" / "support" packages as representative of the logical tiers of the platform. Therefore the service implementation code will go into a respective directory such as internal/core/metadata or internal/export/distro
  • We have to refactor database-specific types out of our domain model (such as the BSON ObjectIDs)
    This should instead be a string on the model and the Mongo provider itself will be responsible for validating any platform specific datatype requirements.
Would the Mongo provider (or other db providers) export a function that would allow other code to validate ids?

Also this still doesn't solve the problem that we're using actual database ids in our REST APIs.  It's probably outside the scope for Dehli, but I think we should give strong consideration to moving to a guid model for ids as Steve Osselton suggested at the last F2F.

There's also the dual-purpose nature of the Device member of some of our objects that should be addressed as well (the current solution is a band-aid).

Regards,
/tony


We had previously discussed keeping the edgex-go/core directory as the location of externally usable code but I’m thinking an edgex-go/external directory makes more sense, as described above. The term “core” has a specific meaning within EdgeX, referring to a specific tier within the platform.

 

The following directories will ultimately go away:

 

Edgex-go/core

Edgex-go/export

Edgex-go/support

 

Their respective clients would go into the edgex-go/external/clients package and their implementation logic would go into

 

edgex-go/internal/core

edgex-go/internal/export

edgex-go/internal/support

 

In particular I want to see if there is any objection to the external package and proposed grouping.

 

Work done so far is here PR #369

 

Thanks,

 

Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA

 

 

 

From: Steve Osselton [mailto:steve@...]
Sent: Monday, July 2, 2018 7:39 AM
To: Conn, Trevor
Cc: EdgeX-GoLang@...; edgex-tsc-core@...
Subject: Re: [Edgex-tsc-core] Delhi -- Cleaner Separation of Internal/External Packages

 

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.