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:

High Level Review of Architecture (by Josh)

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

Solution/Direction Ideas [Jeff]

• 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

Some other needs

• 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