...
- Source code revision control - Development / collaboration tools such as Git make it easy to track what's been done, however using one repository for a project's entire code-base leads to a problem of where does one start and who needs to approve code additions. e.g. with 2 developers, Alice and Bob, if Alice is designing a stock management feature and Bob is designing a forecasting user-security feature, these two pieces are very different pieces of functionality that likely don't depend on one-another, tools such as git aren't really meant to allow Alice and Bob to develop their respective features highly independently.
- Database - A database for OpenLMIS is essentially global-state persistent data. Any changes to the schema is problematic as it could effect many places in the code unintentionally and it also introduces a problem of upgrading production systems that are on a legacy schema.
- configuration - configuration is clearly often feature-related. Setting up R&R form templates is not related to distribution delivery zones.
- localization - localization tags are often clearly feature-related and should be packaged with said features. e.g. tags related to distributions are not very similar to user management.
- process flow - the wiring of how a feature(s) is connected can often change. Routine/coverage data is an excellent example of this where we know many countries want to collect some sort of data, however how it's collected, what's collected, how it's approved, etc can change often.
Why an architecture?
A plugin architecture can help alleviate this problem by defining a small immutable core and extension points to that. This is useful as this small immutable core should change infrequently allowing production databases related to that core to be upgraded in a slower more rigorous process. Extension points define ways in which the small immutable core can be used in different ways to extend the core functionality. Such an architecture can ideally support:
...