Scaling beyond two aggregates

[allforabit]

This looks like a really interesting take on functional event sourcing.

I'm wondering how it'd scale when there's more state parts in the system beyond the demo of two aggregates (restaurant and restaurant menu) that are currently represented as a pair? This file https://github.com/fraktalio/fmodel-demos/blob/main/application/state-stored-system1/src/main/kotlin/com/fraktalio/fmodel/example/statestoredsystem/adapter/persistence/AggregateStateStoredRepositoryImpl.kt could get difficult to manage if it grew to be a more complex. I'm sure there's some sort of fp idea you have in mind though.

Thanks for sharing the project and congrats on the version 2.0 of it.

[idugalic]

Hi @allforabit.
Thank you for your feedback!

combine is an operation/algebra on Deciders (Views and Sagas as well) that is associative. One could compare this operation to adding Numbers in math. In FP this is known as SemiGroup. Because Decider<Nothing, Unit, Nothing> represents an identity it makes it a Monoid

Combining multiple deciders into one is convenient in a Monolith situation, in which you have an Aggregate (application layer) that is using a combined decider. My advice is to combine deciders that have some invariant/relationship (that is why you have Saga as an optional component in your aggregate). If you design it in this way, it should be much easier to distribute each of these small Deciders under independent Aggregates and deploy them separately to achieve better scalability and parallelization.

To your question :)
You are right. Nested Pairs are not convenient.
Unfortunately(or fortunately, I am still not sure :) ) when you combine two Decders with state S1 and S2 respectively, you will get a new Decider that works with the new state of type S1 AND S2 (S1 PRODUCT S2). In Kotlin, at the moment you can express a general PRODUCT/AND relation only with Pair. I hope Kotlin will introduce Tuples soon (vote for the feature ;))

Some options you have:
Consider dimapOnState: Decider1.combine(Decider2).combine(Decider3).dimapOnState(fl: (Sin) -> Si, fr: (So) -> Son) and express your state as a custom domain-specific Kotlin data class (it is also modeling AND relation between the attributes of the class), and avoid exposing Pair. Then, inject this decider into your Aggregate.

I hope it makes sense.

Best,
Ivan

[allforabit]

Yes that makes perfect sense, thanks very much for the comprehensive reply. I watched Jérémie Chassaing's presentation of the concept a while ago and really only partially understood it due to only having a basic understanding of the category theory concepts. Seeing an implementation like this really solidifies things though. The monoid relationship between deciders is really cool. It reminds me of redux's combineReducers except it's much more refined here. I'm going to have another play around with the library, loads of concepts to get stuck in to. Thanks again!

[idugalic]

I was heavily inspired by Jérémie's work and research! I am happy to see that you are inspired as well, and thank you for your feedback @allforabit. As any good abstraction, this project is here to stay. I am happy to see you around!

Best,
Ivan