From fa881f39f0368e49b3386291d125f69ffec41cda Mon Sep 17 00:00:00 2001 From: Lilla Orban Date: Fri, 12 Apr 2024 22:30:13 +0200 Subject: [PATCH] fix(ADR-014) - Add ADR about multiple ModuleCatalogs --- architecture/adr-014-module-catalog.md | 28 ++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 architecture/adr-014-module-catalog.md diff --git a/architecture/adr-014-module-catalog.md b/architecture/adr-014-module-catalog.md new file mode 100644 index 000000000..80f490bad --- /dev/null +++ b/architecture/adr-014-module-catalog.md @@ -0,0 +1,28 @@ + + +| Type | ID | Status | Title | +| ------------- | ------------- | ------------- | ----------------------- | +| ADR | adr-014 | Accepted | Multiple ModuleCatalogs | + + +# Architecture Decision Record: Multiple ModuleCatalogs + +## Context +ComposeUI aims to support many different kind of modules. These modules, that can be started by the ModuleLoader should be stored in ModuleCatalogs and every module should have its unique module id. The user should have the ability to handle multiple ModuleCatalogs with the ModuleLoader. + +General problem statement: +- When multiple ModuleCatalogs are used, some modules could have the same module id in different ModuleCatalogs which could cause issues while starting or stopping the module via the ModuleLoader. + +## Decision +- If the same module id is being used for multiple modules (likely in different ModuleCatalogs), the first occurrence will be used. In case of multiple ModuleCatalog registrations, the order of the registration determines which module can be used. + +# Alternative solutions that we considered +- Throwing an exception when multiple modules have the same moduleId either in one or multiple ModuleCatalogs. This might cause an issue that is unresolvable by the developer or the enduser. +- Prefixing the modules with the name of the ModuleCatalog, but prefixing ids would be non-standard. +- Aggregating the registered ModuleCatalogs should be implemented by the developer of the application. + +## Consequences +- Our implementation is more permissive than the standard. +- We must ensure keeping the order of the ModuleCatalog registrations as the order of registrations will determine which module is contained by our aggregated ModuleCatalog in case of duplicate moduleIds. +- We must ensure keeping the order of the modules within the invidual ModuleCatalogs as the order of the registered modules will determine which module is contained by our aggregated ModuleCatalog in case of duplicate moduleIds. +- We must ensure this order when fetching modules asynchronously from the ModuleCatalogs. \ No newline at end of file