Topics

Delhi -- Cleaner Separation of Internal/External Packages

Trevor.Conn@...
 

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

 

vinoyang
 

Hi Trevor:

I totally agree the decisions. But two questions :

  1. What's the layout of internal modules' models package : one model package shared by all modules OR many model packages (and split some models which should not been shared and package into the specific modules)
  2. Can we refactor this in a separated branch? Not in master branch, so that we can develop features and fix issues normally.

Thanks
Vino

Trevor.Conn@...
 

Dell Customer Communication

Vino – To answer your questions:

 

1.)    Initially, just to get the restructuring done, picture the contents of core/command, data and metadata being moved there as close to as-is as possible. There will also be a new models package for internal use. This will position us for a wider refactoring hopefully using DDD principles as a guide. An example of what this might look like (albeit without the package re-org being discussed in this thread) can be found in the holding area. This refactoring will then obviously change the structure of the packages in /internal, but who cares because applications won’t directly reference them.

2.)    I don’t think this will be necessary. I think the restructuring can be done fairly quickly and as a single check-in. We want it in the master branch quickly to stop the bad practice of importing EdgeX’s internals by outside applications and to position us for future efforts.

 

Trevor

 

From: EdgeX-GoLang@... [mailto:EdgeX-GoLang@...] On Behalf Of vinoyang
Sent: Friday, June 29, 2018 10:28 PM
To: EdgeX-GoLang@...
Subject: Re: [Edgex-golang] Delhi -- Cleaner Separation of Internal/External Packages

 

Hi Trevor:

I totally agree the decisions. But two questions :

  1. What's the layout of internal modules' models package : one model package shared by all modules OR many model packages (and split some models which should not been shared and package into the specific modules)
  2. Can we refactor this in a separated branch? Not in master branch, so that we can develop features and fix issues normally.


Thanks
Vino