2022-09-08 Developers Deep Dive Call

Owned by Uwe Wahser
Last updated: Dec 15, 2022 by Alex Motoc
2 min read

 

Overview

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)

  • @Patrick Delcroix

  • @Dragos Dobre

  • @Marco Kalin

  • @Alex Motoc

Topic Proposals:

  • Modular Architecture

Presentations / Attachments

  File Modified
No files shared here yet.

Setting the Stage for Today

What is a module in the openIMIS context?

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 …

What do we need for our documentation & communication?

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?)

What’s it good for?

  • 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.

What has been done so far?

Limited Target for today

  1. Identify our modules

    1. Start with BlueSquare's graphic (one box = one module? one group = on module?)

    2. Group at least FE & BE into one module, maybe even more

  2. Cluster the modules according to JLN Process Groups (colors)

    1. some modules will serve multiple Process Groups, let’s try to still find the primary process group

    2. some modules will just have technical purposes

  3. Assign our sources to modules

  4. Homework: rearrange module pages accordingly and update them with property boxes

Minutes

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)

 

Additional Resources

Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/