2018-2-06 Meeting notes

Date

06 Feb 2018

7am PST / 4pm CET

Meeting Link

Note we're using Zoom now:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/737202874

Or iPhone one-tap :
US: +16699006833,,737202874# or +14086380968,,737202874#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
Meeting ID: 737 202 874
International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF

Attendees

• Ben Leibert
• Brandon Bowersox-Johnson
• Chongsun Ahn (Unlicensed)
• Craig Appl (Unlicensed)
• Nikodem Graczewski (Unlicensed)
• Paweł Albecki (Deactivated)
• Paweł Gesek
• Peter Lubell-Doughtie (Unlicensed)
• Sam Im (Deactivated)
• Sebastian Brudziński
• Josh Zamor
• if you don't see your name feel free to add it

Goals

• See discussion items

Discussion items

Notes

DDD and package name improvements

Problems:

• lots of packages in a flat style in a service
• things are grouped together more by type, rather than by logical nature (e.g. exceptions are grouped together, not grouped alongside where they're defined)

Feedback:

• Overall:  makes sense to align around a typical 3 layer arch:  presentation, domain, repository:  https://martinfowler.com/bliki/PresentationDomainDataLayering.html
  • In infrastructure layer, it really just looks like a repository layer.
  • A seperation of "web" and application service makes sense to me
• Use of package private scope of Java  - we could use a more concrete plan to see if we're taking advantage of this
• Should database repositories and repositories that are backed by a different service use the same interface? Consider potential differences in error handling.
• Is the repository name overused when used for both database backed and service backed? 

Next steps:

• Make the example more concrete - present a basic diagram, perhaps look at example service.

Mobile Strategy

Goal:  list out the tech considerations for UI Mobile onto this wiki page https://martinfowler.com/bliki/PresentationDomainDataLayering.html

Feedback:

• diagram needs to make it clear what a system integration would be (to ODK2 or OpenSRP) as opposed to a direct mobile app interfacing directly with OpenLMIS REST API over HTTP with JSON.
• what does 100+ mean? Should we define workflows based on the volume of data?
• Should we explicitly call out "shipping a mobile library" rather shipping an OpenLMIS app as a possible strategy?

Action Items

• Paweł Albecki (Deactivated):  take the feedback from the DDD and package name improvements and show through a diagram and/or use of the example service what it'd look like given that feedback
• Josh Zamor:  re-write the key requirements section to address the workflow to non-functional requirements (the what does 100+ products mean)?
• To the group:   bring up what you'd like to see as part of the technical mobile strategy in the dev forum (Product Committee may look at some of this feedback)