ThembisileNGQ / Akkatecture

a cqrs and event sourcing framework for dotnet core using akka.net
https://akkatecture.net
MIT License
524 stars 54 forks source link

Update on missing feature and other enquires #40

Closed atulmish closed 5 years ago

atulmish commented 6 years ago

I’d been playing around with this framework and its awesome in the sense that it solves a lot under the hood. However, I have a few questions and enhancements proposal. I will be happy to contribute for the same as well.

How to implement domain services and anti-corruption layer in this framework. Often we deal with operation the don't fit in the aggregate root and also integrate/extend legacy and third parties' code. An example showing the implementation of domain services and anti-corruption layer would be really handy. This can potentially be part of the framework as first-class citizens and enrich the framework.

How can we rehydrate the aggregate root at the point when its required (lazy rehydration) or on-demand rehydration rather than keeping in-memory persistent actor as a child of the manager? This will potentially reduce memory footprints. This can perhaps be made configurable in the Akkatecture config,

Finally, any updates/plan on the missing following features: • aggregate state snapshotting • scheduled jobs

Lutando commented 6 years ago

These are very good questions. I can add that to a list of examples that I would like to complete for version 1.0.0 of the framework, doing domain services or anti-corruption layers in cqrs can be done in quite a few ways, so my example might be opinionated somewhat. To be transparent im working on the read model side first, then snapshotting, then it will be soon ready for 1.0.0

When it comes to aggregate state snapshotting, it is on the highest priority, and is really needed by year end, so keep an eye out for that.

As for akka.net it kinda works in an on demand fashion and the actors live in memory as long as they have been incarnated, for example, if i have a thousand persistent actors who persist through some non-in-memory storage (as it should be) a particular actor will only be incarnated when something is asked of it (being told a command), and yes that actor will live in memory with its hydrated state so long as you dont call for that actor to be retired using Context.Stop(Self) which will kill that actor and free up its memory footprint. So in short, actors are lazily loaded it is just that they are not explicitly killed off by the akka framework.

as for scheduled jobs, this is something that is easily added on later, I do not see myself with enough time to complete it by the v1, however its a feature I would highly prioritize shortly after that.