Current state

It’s a regular practice on the FOLIO platform to separate business logic and data access layer in two dedicated modules. At least these modules follow the pattern https://github.com/search?p=2&q=org%3Afolio-org+%2A-storage&type=Repositories:

• mod-circulation-storage
• mod-source-record-storage
• mod-orders-storage
• mod-courses
• mod-invoice-storage
• mod-organizations-storage
• mod-data-import-converter-storage
• mod-finance-storage

The following can be mentioned among the main pattern benefits:

• General separation of concerns,
• Potential capability to change the underlying database provider (e.g., Mongo vs. Postgres),
• Single data access point which can be extremely useful if there are many consumers of data (this allows to manage load),
• Potentially better scalability of either business logic or DAO.

While this pattern is well known and provides certain benefits mentioned above, it also has drawbacks, both general and FOLIO specific:

• Storage module is just a proxy between HTTP and JDBC,
• High load on central FOLIO modules and components, namely OkApi and mod-auth - when a simple call to data storage leads to a number of HTTP calls in between several other modules,
• In many cases a Business module being a data owner (and often - the only data consumer) is to follow FOLIO rules with permission verification etc.,
• Large number of modules leads to redundant complexity and resource customization (since every module running in JVM consumes additional memory, CPU and network).

Proposal

Avoid dedicated *-storage modules where possible, and locate their logic within business modules. Consider this as a recommended approach for newly created modules.

Expected benefits

• Significantly reduce number of modules,
• Simplify cross-modules dependencies and improve general manageability,
• Free up FOLIO resources including OkApi, mod-auth etc.,
• Improve hardware resource utilization (memory, network, CPU),
• Enable new capabilities (e.g., optimistic locking on databases to improve data consistency and address some of https://folio-org.atlassian.net/wiki/display/DD/Folio+issues+with+Data+consistency, data versioning),
• Simplify development process.

Proposed approach

• Identify use cases when combining of business and storage modules in one are justified, and make a recommendation checklist
• Newly created and based on Spring modules can follow new pattern from the very beginning
• During the very first module following this approach one can document known tips and recommendations resulted in a kind of guide
• Evaluate if a migration for existing modules is justified
• Concern is that legacy storage modules can be tightly coupled with current platform capabilities (HTTP, Vert.X, RAML etc.) which does not allow quick refactoring. So, current vision is to leave existing modules as is without  migration

Any constructive thoughts and comments are welcomed.

Check if this approach is applicable 

• Newly created module
• Business module (being a data owner) is the only data consumer
• .. anything else?