...
This effort is led by architects and executed by developers.
Coming Soon: Additional details on the approach we’re taking here.
Considerations
Application dependencies exist, and always will. It’s ok for applications to depend on other applications. That said, one of the goals here is to avoid the situation where you literally need to enable ALL applications or none of them because there are so many interdependencies.
Circular dependencies are problematic. At the moment, modules which depend on each other must reside in the same application. These may be good candidates for adjustments/refactoring as to unblock further refinement of the applications these modules comprise.
Tight coupling exists in many areas in Folio, where it shouldn’t or doesn’t need to be. This is one or the major hurdles we face in this effort. Addressing this will require some work. Documentation describing various techniques, when they’re applicable, their pros and cons, etc. is forthcoming. Example: orders has required dependencies on several inventory interfaces. Ideally these would be optional dependencies, allowing orders to be used w/o also requiring inventory.
New modules should not be added to the mega applications. Doing so is only making this effort more difficult. Instead new applications should be created. If needed, these can always be combined with other applications, split up further into additional applications, etc. later on.
...