Rearchitecture: High-Level Design (TECH)

Description: Discuss rearchitecture to address identified technical pain points, propose high-level designs 

Leads: Karl, Josh

Rapporteur/Notetaker:  Rich

Audio recording:  High level Architecture d2s1.mp3

Notes from Session:

• Traditional 3 layer

• Requests go to controller, thin layer of mybatis to database

• Arranged in gradle sub-projects, fairly logical though all javascript/controllers/front-end stuff is in openlmis-web, including migration and authentication.

• Some of the bigger problems: 

•  

  • Migration scripts are sequentially named.  Too many to get an idea of what's going on.

  • Encapsulation:  no domain model, mainly a transactional model

  • Error handling:  no structure, just throwing a runtime exception and moving on.

  • Not leveraging single page application model:  it's really a "collection of single page applications"

  •  

    • Unnecessary bandwidth usage.  TW and JSI encountered performance issues in various projects

    •  

      • Compression helped (verified by JSI in other deployments).  TW studying CDN.

      • Many of the standard libraries, like Angular, are using minified versions, but OpenLMIS angular/JavaScript scripts are NOT minified 

    • Specific library version dependencies, so it's difficult to tell whether a specific version is required or not. 

• Some inspirations from a TW-built PtP lending platform:

•  

  • Described a complex stateful operation carried out as a series of RESTful calls, which can be strung together between websites and mobile devices.  A good analogy is a shopping cart, where someone may add something to a cart on their desktop, then view and buy it via mobile (These are long transaction-like processes, state is stored in domain model)

  • Benefits:  once domain model is stable, hides complexity of processes, clients just need to invoke the series of RESTful calls to fulfill the process.  This could apply to processes like R&R

  • This work extremely difficult to do incrementally - implies a rewrite of OpenLMIS.  This time around, we have the benefit of the domain knowledge and requirements up front.

  • For application to OpenLMIS:  need core domain model, then define processes (like R&R)

  • Difficult for offline operation

• OpenLMIS lacks a domain model

• [OpenLMIS could export a "star schema" for reporting and handling extensible fields]

• Discussion of business logic separation in a domain model [Adam]

•  

  • Domain is about data management

  • Service layer is about the business process

  • General agreement that variations on this theme exist.

• "Does OpenLMIS need a domain model?"

• Common business problem is updating R&R, say adding a new tab with some extra data to collect - how does this fit in the TW PtP model?

•  

  • Thought problem:  add DOB to every line on a Req

  •  

    • Extend the domain object via name-value pair

    •  

      • Does not add a column to the DB.  Need to export data (via star schema or other technique) for reporting and such

  • Subclass business logic for validation

  • UI:  new HTML files

  • Spring selects new versions at build and runtime

• Need "contribute back" process (coming in further sessions)

• Need DB update strategy

• Reporting is a perennial need and request from ministries.  Need a solid reporting solution

• Need to define extension points for processes like R&R

Open

Open