Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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-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 case:  adding new service -- Informed Push -- as part of Reference Distribution

  • 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:  adding a Strategy to Requisition

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!
  • 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
  • No labels