Versions Compared

Old Version 4

changes.mady.by.user Rich Magnuson

Saved on

compared with

New Version 5

changes.mady.by.user Rich Magnuson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

  • 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

Use Cases

Common Use Cases the solution must address.  Assumes definition of terms, like "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

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