@David Asem joined #fineract. They’re also new to Mifos.
#fineract 2026-02-26
@Aryan Singla has joined the channel
Hi @Aleksandar Vidakovic
I'm interested in the EDA for stand-alone modules GSoC project.
I analyzed fineract-provider and found tight coupling in
disburseLoanToSavings (direct call to accountTransfersWritePlatformService). I'm planning to propose refactoring such "one-way" calls using Spring Business Events to make modules independent.
Am I on the right track? Should I focus more on any specific module like "savings group support"? Thanks!
I'm interested in the EDA for stand-alone modules GSoC project.
I analyzed fineract-provider and found tight coupling in
disburseLoanToSavings (direct call to accountTransfersWritePlatformService). I'm planning to propose refactoring such "one-way" calls using Spring Business Events to make modules independent.
Am I on the right track? Should I focus more on any specific module like "savings group support"? Thanks!
Hi @Aryan Singla... well... that's a tiny bit of the whole story... the steps to consider here:
- first we need to migrate modules to the new command processing (see FINERACT-2169), because that gets us type-safety and less boilerplate code... if we don't use the handcrafted JSON de-/serialization then we don't have to care about any tight coupling these have... they just go away (the best case)
- once we have type-safety we can use the IDEs refactoring tools (again) and use tools like "Used by..." etc. ... that will obviously help to find any hidden dependencies
- the generalized version of the case you described: find patterns in the packages/"modules" that can be replaced by one way Spring Application Event publishing; that immediately removes those direct dependencies; that's the easiest case of removing the tight coupling; before we do that we should standardize on naming conventions... just because some character combinations pass the compiler doesn't mean they are a good choice; so we have to prepare here a bit of documentation for the next people that want to help out and avoid too much creativity in the wrong place
- the really interesting use cases are those where 2-way communication is necessary aka some function is called and results need to be processed by the caller; I've done something like that in a recent refactoring in fineract-document... which is now completely independent (technically at least) from any other (non-core and fineract-command) dependency (which would be the desired goal... if possible); but again, that needs to be documented too
I think that's it in a nutshell
ah... one more... I'll copy verbatim a part of a conversation that I had with someone else on that topic recently:
```one of your colleagues posted this question concerning the event driven project: "Could you guide me on where to begin analyzing coupling in the codebase?"
my answer (just copying verbatim for speed and efficiency):
we have this "document management" module (it does what it says... upload/download of files, we save some metadata like names, mime types, size in the database... that's it)... but for some (weird) reason we made a distinction between "documents" (like PDF, word, excel...) and images (png, jpeg, gif...); the latter is only used (currently) in combination with the "staff" and "client" domain (think of: profile pictures for people)... now what's the difference between an image and a document (rhetorical question)? well... there is none, the only difference is the mime type (like for any other document)... it's just blobs of binary data with some metadata. now unfortunately the initial implementation made that distinction and even after the most recent refactoring it's still there to keep backwards compatibility. but one major improvement was made: before image related files had a hard dependency on the staff and the client packages, because the image uploads/downloads are identified by the main domain entity that these files are associated with (another strategy that should be challenged... but that's for another day); so for now we have to roll with these decisions: when a file is uploaded it is not identified by it's own ID, it's identified (if we take profile pictures as an example) by the entity domain (e.g. "clients") and the domain entity's ID (i.e. "the client's database ID")... so the REST endpoint would look something like "/v1/clients/23/image"... so, that's not too great, because now we have these two domains files/documents/images and clients entangled... which is (was) reflected in the code
we would use repository interfaces from the client package in the document package and vice versa... which creates a very weird and nasty circular dependency situation
if you look at the current implementation of the document module then you will see there are no references to client or staff or any other package there anymore (we had a similar situation for "bulk imports", another package, that was using document management to upload excel sheets for setting up clients, offices etc. etc.)... so how did we do this?
have a look here... https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]re/documentmanagement/service/ImageReadPlatformServiceImpl.java ("EntityImageIdAdapter")
... the interface: https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]astructure/documentmanagement/adapter/EntityImageIdAdapter.java (which is available in finerct-core... visible to every other package in the system)
... and then finally the implementation of this interface:
https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]che/fineract/portfolio/client/adapter/ClientImageIdAdapter.java
https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]he/fineract/organisation/staff/adapter/StaffImageIdAdapter.java
so... what happens here?
well... on the image management side we only need to know that something exists out there that implements the interface "EntityImageIdAdapter"... we don't know the specific implementations and we don't need to know them
and because we don't know them they are injected as a list of beans as you can see
the point here is that every time we upload a new image we need to store it database ID WITH those other domains (client, staff)... so, instead of using directly the client repository or staff repository we iterate over the injected entity image adapters and use the functions exposed there to peek and poke data back and forth between the domains
tomorrow if we add yet another domain that has profile pictures (maybe "external collaborators"... doesn't matter) then we just have to implement EntityImageIdAdapter for that new domain and nothing needs to change in the document management
that's in a nutshell the type of solution(s) we need to break all these direct dependencies (where it makes sense)
note: sometimes a direct dependency is perfectly fine... e.g. there is some kind of currency service... obviously that is some kind of "core" service that is needed by a lot of different domains/packages/modules (loans, savings accounts, ledger etc. etc.)
the trick here is to identify the dependencies that tie a otherwise perfectly standalone module unnecessarily to some arbitrary other module... like in the above example with document/image management and client and staff domains```
```one of your colleagues posted this question concerning the event driven project: "Could you guide me on where to begin analyzing coupling in the codebase?"
my answer (just copying verbatim for speed and efficiency):
we have this "document management" module (it does what it says... upload/download of files, we save some metadata like names, mime types, size in the database... that's it)... but for some (weird) reason we made a distinction between "documents" (like PDF, word, excel...) and images (png, jpeg, gif...); the latter is only used (currently) in combination with the "staff" and "client" domain (think of: profile pictures for people)... now what's the difference between an image and a document (rhetorical question)? well... there is none, the only difference is the mime type (like for any other document)... it's just blobs of binary data with some metadata. now unfortunately the initial implementation made that distinction and even after the most recent refactoring it's still there to keep backwards compatibility. but one major improvement was made: before image related files had a hard dependency on the staff and the client packages, because the image uploads/downloads are identified by the main domain entity that these files are associated with (another strategy that should be challenged... but that's for another day); so for now we have to roll with these decisions: when a file is uploaded it is not identified by it's own ID, it's identified (if we take profile pictures as an example) by the entity domain (e.g. "clients") and the domain entity's ID (i.e. "the client's database ID")... so the REST endpoint would look something like "/v1/clients/23/image"... so, that's not too great, because now we have these two domains files/documents/images and clients entangled... which is (was) reflected in the code
we would use repository interfaces from the client package in the document package and vice versa... which creates a very weird and nasty circular dependency situation
if you look at the current implementation of the document module then you will see there are no references to client or staff or any other package there anymore (we had a similar situation for "bulk imports", another package, that was using document management to upload excel sheets for setting up clients, offices etc. etc.)... so how did we do this?
have a look here... https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]re/documentmanagement/service/ImageReadPlatformServiceImpl.java ("EntityImageIdAdapter")
... the interface: https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]astructure/documentmanagement/adapter/EntityImageIdAdapter.java (which is available in finerct-core... visible to every other package in the system)
... and then finally the implementation of this interface:
https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]che/fineract/portfolio/client/adapter/ClientImageIdAdapter.java
https://github.com/apache/fineract/blob/701cfae60bc70de68e41b9b4345e0c393ec3d19a/f[…]he/fineract/organisation/staff/adapter/StaffImageIdAdapter.java
so... what happens here?
well... on the image management side we only need to know that something exists out there that implements the interface "EntityImageIdAdapter"... we don't know the specific implementations and we don't need to know them
and because we don't know them they are injected as a list of beans as you can see
the point here is that every time we upload a new image we need to store it database ID WITH those other domains (client, staff)... so, instead of using directly the client repository or staff repository we iterate over the injected entity image adapters and use the functions exposed there to peek and poke data back and forth between the domains
tomorrow if we add yet another domain that has profile pictures (maybe "external collaborators"... doesn't matter) then we just have to implement EntityImageIdAdapter for that new domain and nothing needs to change in the document management
that's in a nutshell the type of solution(s) we need to break all these direct dependencies (where it makes sense)
note: sometimes a direct dependency is perfectly fine... e.g. there is some kind of currency service... obviously that is some kind of "core" service that is needed by a lot of different domains/packages/modules (loans, savings accounts, ledger etc. etc.)
the trick here is to identify the dependencies that tie a otherwise perfectly standalone module unnecessarily to some arbitrary other module... like in the above example with document/image management and client and staff domains```
might give a little more insight into what happened with the fineract-document example use case related to tight coupling
ah, and finally: stuff like this needs to be prioritized... we cannot start immediately with the "bread-and-butter" modules (anything transactions, general ledger, loans, accounts...), because there will be - no matter how accurate the planning - a learning curve and improvements that show up when we really do the work... and it's obviously better to do the learning on "modules" that are not immediately in the critical path
hope this helps you (and anyone interested) to clarify this a bit more
@A1_ 432_Deepthi joined #fineract. They’re also new to Mifos.
@Ibijola Adetayo joined #fineract. They’re also new to Mifos.