FINERACT-2644: Add event-driven modularization design doc (FSIP-12)#6031
FINERACT-2644: Add event-driven modularization design doc (FSIP-12)#6031mansi75 wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new AsciiDoc design document describing a proposed event-driven approach to enforcing module boundaries between Fineract feature areas (via fineract-core read contracts and fineract-command write contracts).
Changes:
- Add a new design document:
Event-driven architecture for modular design.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
… of documentation build
…patibility Signed-off-by: mansimaurya <mansimaurya75@gmail.com>
| permitted cross-feature dependency: reads cross a boundary as a `fineract-core` interface | ||
| returning a DTO, writes cross as a `fineract-command` command or domain event. Every direct | ||
| feature-to-feature import is migrated to one of those two mechanisms, in risk order, and an | ||
| ArchUnit rule is activated in CI to keep the boundary from eroding again. A Spring Modulith |
There was a problem hiding this comment.
We dont have any ArchUnit lib or rules...
There was a problem hiding this comment.
Neither Spring Modulith is not used.
There was a problem hiding this comment.
I have added the Spring Modulith for cross-feature boundary test so I included that in the document also since we are going forward with the documentation along with the implementation. I will update it accordingly
adamsaghy
left a comment
There was a problem hiding this comment.
@mansi75 @vidakovic This modularization.adoc is describing situations and libs which not exists in Fineract. Should we first start the work before having this doc?
Description
This PR adds a new design document,
Event-driven architecture for modular design, to the Fineract documentation (fineract-doc).The document describes the proposed approach for getting Fineract's module boundaries under control. Today, feature modules import each other's internal classes directly (e.g. loan reads savings entities, savings calls accounting services, accounting depends on organisation repositories), and nothing enforces the use of the existing
fineract-coreandfineract-commandshared modules. The doc proposes making those two modules the only permitted cross-feature dependency — reads cross a boundary as afineract-coreinterface returning a DTO, writes cross as afineract-commandcommand or domain event — and migrating all direct feature-to-feature imports to that model in phased, risk-ordered steps, with an ArchUnit rule activated in CI once the violation count reaches zero.Changes in this PR:
fineract-doc/src/docs/en/modularization.adoc(the design document).fineract-doc/src/docs/en/index.adocvia aninclude::directive so it renders in the documentation build.This is a documentation-only change. There are no code, REST API, schema, or behavioural changes.
Related JIRA: https://issues.apache.org/jira/browse/FINERACT-2644
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!
./gradlew :fineract-doc:doc(docs build green).Your assigned reviewer(s) will follow our guidelines for code reviews.