Date: 08.09.2022
Follow-up-Meeting: 2022-09-15 Developers Deep Dive Call
Objective: Weekly space for deep dive topics
Participants: (kindly only add your own names, not those of other participants)
Topic Proposals:
Modular Architecture
No strict definition of what a module is, but everybody talks about it:
Implementers: “A thingy that does what I need to support the work of my users.”
Developers: “All the code that fits into one github repository (not more than 5.000 LOC per module)”
Anybody else: whenever I need a techy sounding word for group, bunch, pile, collection, cluster, piece, lego …
Obviously we have a problem here …
A link between the business view and the technical view.
In practical terms: a consolidating wiki page that :
bundles source components (What do I need?)
assigns them to business processes (What can I do with it?)
explains the supported functionality (How does it work?)
We need to be able to communicate a common understanding of or features on a high level.
If done according to standards (e.g. JLN), it is easier to compare openIMIS to other products.
these standards may vary according to the domain / sector - we might need more than one
In the long run this modularisation can also serve a stricter separation of system components e.g. towards a service oriented architecture.
Basic Module documentation in wiki pages: openIMIS Modules
Mapping of modules to JLN Business Processes: JLN Process - OpenIMIS Mapping
Toumai study (French language version only): Webinar: openIMIS pour l’Assurance maladie : L’approche modulaire - 15.03.2022
BlueSquare has come up with a very useful graphic as a result of the migration: openIMIS Modules
We have started to structure essential information items per module page for an automated overview table: JLN Process - OpenIMIS Mapping
Extensive resource page: Modular Architecture [Notes]
Identify our modules
Start with BlueSquare's graphic (one box = one module? one group = on module?)
Group at least FE & BE into one module, maybe even more
Cluster the modules according to JLN Process Groups (colors)
some modules will serve multiple Process Groups, let’s try to still find the primary process group
some modules will just have technical purposes
Assign our sources to modules
Homework: rearrange module pages accordingly and update them with property boxes
Remarks:
JLN are business activities will use several modules BUT many processes will use the same modules
A module is an element that is included in the assembly (backend/fronEnd) recipe (openimis.json) if this definition changes then will need to replace module terms we are using today → I fear that will bring a lot of confusion (Patrick)