2018-2-06 Meeting notes
Date
Feb 6, 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 (Deactivated)
if you don't see your name feel free to add it
Goals
See discussion items
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
10m | Agenda and action item review | @Josh Zamor (Deactivated) | Action item review from https://openlmis.atlassian.net/wiki/x/vAAND Action items from last time: @Mateusz Kwiatkowski to create a Proof of Concept RESTful design for requisition approval as a resource, and present next time @Chongsun Ahn (Unlicensed) to add docs on http caching / dtos |
25m | DDD and package name improvements | @Paweł Albecki (Deactivated) | |
25m | UI Mobile Strategy | @Brandon Bowersox-Johnson |
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