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
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)
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.
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)