Modularity/Extensibility decisions, questions

Use Cases

Common Use Cases the solution must address.  Assumes definition of terms, like "Reference Distribution"

Use Case 1:  Project deploys "vanilla" OpenLMIS Reference Distrubution

For this simple case, we want to deploy the reference distribution.  No additional modules or enhancements

• Seeding data?
• Configuration:  email, db connection, and other items typically found in default.properties

Use Case 1a:  Project updates "vanilla" OpenLMIS installation to a newer version

A project has deployed the stock OpenLMIS Reference Distribution.  Over time, updates were made to the Reference Distribution services, e.g. updates to Requisitions.  The project now wishes to update the installation to use the newer services.  Must consider DB migration, etc.

Use Case 2:  Country Project creates new Service, deploys as part of Reference Distribution

A country project enhances the OpenLMIS Reference Distribution with a new service and deploys it.  The module is not part of the Reference Distro, but is published and available for others to include in their own distribution.  Use case should include how other projects obtain and leverage this module.

Use Case 2a:  Project extends a core domain model

How does an implementer extend a core domain model?  For example, adding the "color" field to a Facility, or additional attributes to a User.  How are these extensions added to a data store, how are they accessed via web services?  How are they used in queries (e.g. find all Facilities where color==blue and type=warehouse)

Use Case 3:  Add a new service -- Informed Push -- as part of Reference Distribution

We want to uate the reference distribution with a new capability.  For this example, say it is Informed Push

• Update reference distribution
  • Update docker image configuration to add new docker instance for Informed Push.  Will hold image of the new Spring boot application
• Starting published Spring boot application template, create new Spring boot application.  Write informed push logic here
  • If extensibility is foreseen, instead write informed push as a Spring module  
• UI:  create new UI component (starting from published UI template).  Update reference UI application to include

Use Case 4:  Adding a Strategy to Requisition

How does a project insert their own strategy to an OpenLMIS extension point?

Modularity

Hybrid approach:

• OpenLMIS "core" composed as a Spring Boot application.
  •  Core modules are created as Spring components.  This is likely the requisition/fulfillment set of services
  • The OpenLMIS application is a composition of these components into a distribution.  The distribution:
    • assembles various components together using standard Spring wiring, using Maven to locate dependencies
• See 

Repositories

This section is outdated compared to later discussion.  

• OpenLMIS Organization in GitHub publishes several repositories:
  • openlmis-core-domain
    • One or more modules for reference entities, such as Users, Facilities, etc.
    • Artifacts:  jar file, than can run as a single service
  • openlmis-requisition-core
    • Spring boot application.  Composed of several Spring modules (see openlmis-requisition-module-xx)
    • Artifacts:  jar file, that can run as a single service
  • openlmis-requisition-module-xx
    • where xx is requisition, fulfillment, etc.
    • holds core modules that are composed in openlmis-core
    • Artifacts:  jar file for each module
  • openlmis-requisition-module-xx-ui
    • UI components that match the service (pending ref UI strategy)
  • openlmis-reference-distro
    • projects fork or copy this to create the actual application.  Reference distribution produces a set of docker images
      • project could create a monolithic app, too. 
    • Artifacts:  the actual OpenLMIS applications, made up of several docker images, stitched together with Docker Compose and configuration (such as DB connecton details if we're sharing a Postgres image).
      • each Docker image is domain bounded.  E.g. one for Requisition/core, one for Inventory Management, one for core domain (ref data), another for UI, and potentially others for add-on modules
  • Reference UI

Questions/Issues

• Reference UI - how to build, compose
  • Do modules package UI into the same repo as module code, or a separate repo?
  • Still need reference UI solution that pulls together various web components, both "core" and additional modules
• Database - how to extend core domains, or even new module domains?
• Domain model areas that need more attention:
  • Products, especially for packaging (GTIN/GS1), "kits" and some concept of "product Types" to satisfy scenarios such as, "I need 100 doses of BCG (not "BCG 10" or "BCG 20")"
  • Hierarchies, such as supervisor nodes, Requisition Groups, etc.
  • Design for Program Data
  • Should Programs have different supply models enabled for different parts of the supply chain, e.g. requisitions for one portion, informed push for another
• What to call these docker image boundaries...Feature?  Vertical?  Service?
• Extending domains, e.g. adding attributes to Facilities
• Upfront cost of creating docker images?  
  • build, deploy, logging, etc.  Also, remember this needs to run on (Windows) laptops.  Minimum hardware requirements?
  • Promotes vertical development amongst different teams