Kapil First thanks for bringing ideas. Im curious.
But I’m confused by this. Are you proposing something specific to Fineract? A specific refactoring pattern? The git repo you shared seems like a proof of concept for a generic cqrs, not domain specific..? A bit of history : We already have the CQRS pattern in Fineract and when it was built initially there wasn’t time to fully complete it. (2011) The half baked CQRS was then modified again (partly) in 2016 by a developer with a different conceptual understanding, then heavily modified recently (2022-2025), to try to remove some artificial processing limitations. As I recall that was a huge undertaking and may also be only partly completed across Fineract components. It was inspired in part by people like Martin Fowler writing about this: “The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary ofCommandQuerySeparation <https://martinfowler.com/bliki/CommandQuerySeparation.html>. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.” https://martinfowler.com/bliki/CQRS.html (It’s a short article ) You reference the 23 GoF design patterns. So, is this a theoretical or actual design discussion you want to have for Fineract, or what am I missing? If a massive refactoring, who would do this? Is it truly needed? How would testing for regression be done? Thanks for clarifying. On Sat, Oct 18, 2025 at 12:16 AM Kapil Panchal < [email protected]> wrote: > I have added a git repository for the NewCommandProcessingInfrastructure, > as described in my previous email. This is the link > https://github.com/NewCommandProcessingInfrastructure/finance/tree/main > > On Sun, Oct 5, 2025 at 10:52 AM Kapil Panchal < > [email protected]> wrote: > >> The Apache Software Foundation’s ecosystem is a remarkable collection of >> projects, each representing deep expertise in its own domain. Yet, what >> remains elusive is a cohesive workflow that connects the entire software >> development lifecycle — from the origination of an idea, to its design and >> implementation, to its use in production, and finally to the measurable >> impact it creates for the users. >> >> The *New Command Processing Infrastructure* emerges as a unifying >> pattern that brings order to this fragmented landscape. Represented through >> an extensive UML model (attached herewith), it abstracts the complexities >> of command orchestration into a structured yet adaptable framework. This >> pattern is not merely a design construct — it represents an evolution of >> thought, where patterns transcend their traditional boundaries and evolve >> into *architectural frameworks* and *foundational libraries*. >> >> This work aspires to be recognized as the *24th Design Pattern* in >> continuation of the GoF lineage — not for novelty, but for necessity. It >> formalizes a pragmatic approach to command execution pipelines, combining >> *pre-processing*, *execution*, and *post-processing middleware* to >> enable reliability, observability, and event-driven extensibility at scale. >> >> Beyond its technical depth, this effort symbolizes a bridge between two >> parallel universes — *academia* and *development*. While academia >> defines frameworks of understanding, development transforms them into >> frameworks of utility. The missing link between these worlds lies in >> structured research — journal papers that record, analyze, and preserve >> such work for both scholarly and industrial progress. >> >> The Apache Foundation’s openness to research attribution provides an >> opportunity to place this work where it belongs — at the intersection of >> *research, >> design, and development*. By consolidating developer personas — from the >> research-oriented who thrive on theoretical insights, to the >> management-oriented who seek tangible outcomes — this initiative cultivates >> not only a methodology, but a *work culture* rooted in reflective >> innovation. >> >> Following the successful collaborative rollout of the Command Processing >> Architecture with logical design teams, this work is intended for formal >> publication under the *Data Structures and Algorithms (cs.DS)* category >> on *arXiv.* >> >> Just as a teaser, I have attached herewith what the paper would look like. >> >> >> PS: I would need help publishing a paper on arXiv (it's free). It needs >> previous researchers to approve the release of this work. >> >> >> On Fri, Oct 3, 2025 at 10:42 PM James Dailey <[email protected]> wrote: >> >>> Kapil >>> >>> Please start new threads when appropriate. >>> >>> Interesting ideas, and a good target. Perhaps you would like to dig >>> into the apache release process and the github repos I referenced before. >>> >>> https://www.apache.org/legal/release-policy.html >>> >>> see github/ tooling-actionblob/main/readme >>> https://github.com/apache/tooling-actions/tree/main/release-on-atr >>> => release-test.apache.org >>> >>> and see Grails release process (mostly) automated --> >>> https://github.com/apache/grails-core/blob/7.0.x/RELEASE.md >>> >>> Review and then come back with a set of actions and coding for Fineract. >>> >>> Thanks, >>> >>> >>> On Fri, Oct 3, 2025 at 8:18 AM Kapil Panchal < >>> [email protected]> wrote: >>> >>>> I think what is the need of the hour is to have a *Release Alignment >>>> Strategy*. Do we have a release plan that coincides with the release >>>> of all major dependency releases? e.g. Java releases its LTS every 3 years >>>> around September? SpringBoot follows a rough release cycle of 6 month with >>>> releases every May and November? A nice to have would be a plan that >>>> follows these major releases. It also makes it more credible, dependable >>>> and gives confidence of a matured and stable product? >>>> >>>> On Fri, Oct 3, 2025 at 12:49 PM Ádám Sághy <[email protected]> wrote: >>>> >>>>> Hi James, >>>>> >>>>> I dont disagree, but we have a couple way too early work. >>>>> >>>>> Let me give a try to find a commit which is the most “reliable”, maybe >>>>> cherry pick a little. >>>>> >>>>> Regards, >>>>> Adam >>>>> >>>>> On 2025. Oct 2., at 18:37, James Dailey <[email protected]> wrote: >>>>> >>>>> Hi Adam - Thanks. >>>>> >>>>> Today might be a good day to grab a commit point for the release. >>>>> AFAIK, the devs have finished some features as of yesterday and pushed >>>>> some >>>>> additional clean up commits. There is always dev going on, so the task is >>>>> not to find the "perfect" point but one where the features are working >>>>> well >>>>> enough for 90% of the users. I think that point is today. >>>>> >>>>> Does anyone disagree? >>>>> >>>>> >>>>> On Mon, Sep 29, 2025 at 2:44 PM Adam Monsen <[email protected]> wrote: >>>>> >>>>>> Thanks James. I'm happy to do this and I'm ready to start whenever. >>>>>> >>>>>> https://fineract.apache.org/docs/current/#_releases outlines a >>>>>> roughly 17-day process, so I'd expect the same for this release. >>>>>> >>>>>> *I need advice on when's a good time to start the process, and which >>>>>> commit to start from for the release branch*. @Ádám Sághy >>>>>> <[email protected]>, would you please advise? >>>>>> >>>>>> Release process streamline idea: We can branch for the release from >>>>>> any point we choose, so if we happen to have a known good commit (has all >>>>>> the right/complete features, none we don't want, and all tests passed) >>>>>> already, maybe we could use it as-is and shorten the release branch >>>>>> stabilization time. I'd guess the chance of this is small. >>>>>> >>>>>> re: automating the release process: Yep. This needs more/dedicated >>>>>> ideas/research/testing. >>>>>> >>>>>> On Fri, Sep 19, 2025 at 3:32 PM James Dailey <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I’ve asked Adam Monsen to again be the release manager - we have >>>>>>> some issues to get into an official release. Can we get this out by Oct >>>>>>> 7th? >>>>>>> >>>>>>> We are seeking to make the release process more streamlined and >>>>>>> automated as well. >>>>>>> >>>>>>> As part of this we will likely roll release 1.12.x to end of life. >>>>>>> Some important improvements like oauth changes cannot be backported. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>
