... thanks James for the input... I'll try to answer your last couple of questions from my perspective (read: opinionated... take with a pinch of salt):
- *too clever*: the current implementation I suggest that anyone tries to draw a sequence diagram that explains the flow of execution and make it fit on one page vs the new proposal will most likely contain less than a handful of lines. You can apply the same if you take lines of code as a metric... overall the new proposal has less than 50 lines of code that are relevant (I don't know the number for upstream, but I think it's safe to say it's more). If we assume that we can achieve the same results with less code then I think the answer is easy here - *maintainability*: well, see above... the current solution is not documented at all and I am pretty sure I am not alone when I saw "I really can't explain all the steps" (doesn't mean they are not necessary); what I want to say is that the existing solution would really need a lot more explanation than just "CQRS", I think that would be a fair requirement. Admittedly, the new proposal also has no documentation (other than the wiki page and what I wrote in this message). But: I think if I did write it it can fit on one page (with diagrams), this module (it's a real one) has (almost) no external dependencies (other than the frameworks that we use anyway), it makes no assumption about any of the business logic that might or might be passing through (existing implementation fails already there... see CommandWrapper and the various entity IDs that are buried there... this wrapper class should not be aware of anything it transports)... which brings me back to the point of less code which is I think from a maintenance point of view preferrable - *Apache Camel*: ... disclaimer, I really like that framework and used it on a ton of occasions. That being said: choosing a framework is a commitment pretty much like a vendor lock-in. Depending on how you integrate a framework like Camel (this will be more than a JAR file and you can either hide the fact you use Camel from the rest of your app or you fully expose it...) upstream means if for some reason it turns out that Camel is not a good choice or the community doesn't want yet another dependency then we might find ourselves in a refactoring fest to revert things. If you look closely in the proposed sources you will see that first of all there are Java interfaces that propose a contract on how to wire things together... and there not many... which leaves a lot of room for actual implementations (Camel or something else). In fact, 3 or 4 years ago I actually created a drop-in replacement for the upstream SynchronousCommandProcessing service and ran Camel behind the scenes and was actually very happey with the outcome. When I did this there were basically 2 relevant functions that needed to be taken care of. Today there is a lot more going on there and I am not so sure if you could just drop-in Camel effortlessly with the current incarnation of the command processing service. - *Asking Apache Camel's community for opinion*: well, can't hurt... they do stuff like this literally every day, so I am pretty sure whatever we'll exchange with them will be very informative. But that doesn't relieve us from deciding if you want to go all in on Apache Camel it would be anyway a good practice to abstract these implementation details away (aka hide to the rest of Fineract that you are using Camel). If that is the case then we need a contract (aka Java interface). The one that is there won't do it anymore... without major rework... and that is the point. The proposal intends to ensure a gradual non disruptive migration (not open heart surgery) - *whitepapers*, alternatives: I think the first thing that Google or ChatGPT searches will tell you is "use an existing CQRS framework"... and this will most likely show you AxonIQ (a CQRS framework implemented with Spring/Boot)... but that is then even more of a vendor lock in than using a more generic solution like Camel... Axon will force us to use their contracts (internal APIs, Java interfaces etc.), in short: refactor fest, disruptive. There are other low level "solutions" (like LMAX Disruptor) that are somewhat in the vicinity of this type of application, but require work, to my knowledge there is nothing out there we could just magically drop and use without any refactoring. Disclaimer: in one of the 3 drop-in implementations of the proposed command processing I am actually using LMAX Disruptor... its implementation details just don't leak into the rest of the system - *Spring Boot 3 compliance*: yes (buzzword drop: "auto-configuration") - *cutting edge*: not sure how to read this here... is this meant as a requirement or as an argument against the adoption of the proposal as in "too experimental"... as I've written the code I am obviously biased so I leave that to the community to decide and come up with improvements and/or alternatives/arguments if someone doesn't agree Let me know if I skipped something, made an error or was not clear enough. On Thu, Jan 23, 2025 at 5:00 PM James Dailey <jdai...@apache.org> wrote: > Thanks for bringing this to the list. It looks to be a very low level (in > the stack) and therefore, highly impactful. I was there when the decision > was made to adopt this pattern and SynchronousCommandProcessingService as a > flexible improvement to the existing CQRS. I remember asking some > questions, but this was and is, beyond my direct experience. > > > https://cwiki.apache.org/confluence/display/FINERACT/FSIP-5:+New+command+processing+infrastructure > > What I do know is that we should be deliberate with this process, and I > appreciate your write up on wiki. Definitely other architects here should > take a look. > > At times over the past decisions - it feels to me that we try to be "too > clever", and this creates a problem with maintainability. I'd like to make > sure we understand the alternatives as we dig into this. You raised Apache > Camel as an option - would it be worth it to ask someone over in that > project to comment on this? Is there some whitepaper or comparison out > there between the alternatives available? Is this consistent with Spring > Boot 3 ? Is this on the cutting edge? >
