Akkatecture has just completed its Snapshot story on release 0.4.0. With this feature, you can optimise your aggregates during the initial load to speed up aggregate responsiveness. Snapshotting is not at all a new concept but this should give you a few options on how to reduce the load time of your aggregates.

In 2019 Akkatecture will implement resumable projections, a resumable projection (or readmodel) is a smart type of projection that is built up from the event event stream that is durable between deployments. Essentially Akkatecture will give you some APIs that will take care of the underlying mechanisms for you. Like in the akka.net documentation, a resumable projection is a projection that can be built up from any point in your event journal (the beginning, or offset x). It is quite common practice to rebuild your projections from scratch between deployments, especially if your event journals are not unbeleivebly long.

Another goal of 2019 is to have Akkatecture get battle tested in more production environments. As of now, some members of the community are using it in hobby projects with great success.

Don't forget to join the Discord community if you have any questions or are looking for ways to contribute. We always appreciate the help. 😊

Akkatecture began because I found that the lack of comprehensive cqrs and es examples for akka.net was a huge opportunity to help others. I suspect that most akka users, are the ones on the JVM side of the fence, which shows by the higher amount of community members in that open source project. Ok... onwards onto what is Akkatecture philosophically, and why I decided to build it.

Akkatecture is set of constructs and patterns written in C# ontop of akka.net. The main goal of Akkatecture is to allow developers who are using akka.net to model their business domain within the akka.net framework with less friction. Akkatecture is built on reactive messaging & treats events as first class concept, making it highly scalable, thanks akka.net! Akkatecture focusses mainly on messaging integration patterns within your domain so that you dont have to.

Akkatecture uses the actor model as the universal primitive of concurrent computation. This means that aggregates, sagas, jobs, and other domain concepts are modelled within the actor model. Invoking or interacting with the domain is done by having these actors either react through commands (sent from outside of the aggregate boundary), or through domain events, emitted from within the domain boundary, both of which are fundamentally messages. A strong case can be made for using the actor system as a basis for designing your distributed domain, because actors in actor systems embody 3 things fundamentally:

Processing - actors can do work when requested to, the requested work can only be initiated by a message, typically in the form of a command or an event, the locality of this processing is done within the instantiation of an actor itself.

Storage - actors can store local internal state, in memory, and defer the storing of its state to a persistent store. This state is also thread safe from anything outside of the actors locality since actors process one message at a time and cannot be inspected externally.

Communication - actors can communicate with each other using a pre-defined communication protocol. Typically addressed by using location transparent actor addresses. Actors communicate with message passing and that is the only way that the outside world can communicate with the actor system. Messages being commands, or events. The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation. In response to a message that it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other through messages (avoiding the need for any defining of critical sections, or weird mutexs).

Akka based systems have been used to drive hugely scalable and highly available systems (such as Netflix and The Guardian). Even though these companies tend to run into issues at scale on a daily basis, I still see value in modelling the business domain using actors since, with some haggling, they are quite descriptive and indicative of what actually happens in the real world.

Please have a look at our documentation, go through the basic concepts, and the walkthrough to get a good understanding of what Akkatecture looks like.

Please find me on Discord, or file GitHub a issue* for any questions, guidance, or support-y stuff or just say hi👋.

Status of Akkatecture

Akkatecture is still currently in development, however most of the basic building blocks have been built out, but as of yet no v1 to speak of on NuGet.

The next plan is to work on the current core library and branch it out to support:

• typed actor references*.
• persisted event metadata.
• snapshotting state.
• scheduled jobs

*nice-to-have features, not crucial, and might be axed for first version.

Some of the issues highlighted above can be seen here*. However I plan to knock these off 1 by 1 and launch the first beta by June.

---

* Please note, the links in posts written by Lutando have been edited to refer to the "AfterLutz" repositories on GitHub.

-- Akkatecture Maintainers