akka.net - Actor Model and Akka.Persistence

[Alexey Zimarev]

Have anyone tried to implement domain models using the actor model pattern with akka.net?

Akka.Persistence was recently ported to .NET and the sample looks very promising.

Vaugh Vernon talks about similar things for a while but is there anything on github to look at?

[Greg Young]

I've been watching akka.net for some time. It is obviously well behind akka. I'd have to chat more with the maintainers about how comfortable I would be running it in production but it's quite exciting.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Alexey Zimarev]

Not talking about production yet. I would probably consider Project Orleans for production.
My interest is around Akka.Persistence, this would eliminate the need to handle persistence manually. Pluggable storage could mean that possible use of ES as backend.

[Peter Hageus]

It’s been on my mind for quite a while now, and I think my next major project will use actors (bookingsystem, seems like a good fit to me).

 

I’m not 100% sure I want to take on Akka.net as a dependency from the beginning though. Might start with something simple, non-distributed, in-memory, to get a feel for the requirements, and then maybe some kind of adapter for a thirdparty solution if need arises.

 

The technical aspects of the actor model seems pretty well understood and documented, but I would also love to see more in the context of ddd.

 

I assume you’ve seen this:  http://www.amazon.com/dp/0133846830

(theres that bloody enterprise word again though ;))

 

/Peter

--

[Alexey Zimarev]

Yes, I know about this book and in fact it is available for quite a large bit on Safari books online.

I think the actor model has most advantages when some aggregates live in the intensive change mode. With actor model, these aggregates can stay online and don't need to be retrieved for each command. This model is possible with Project Orleans too.

Akka Persistence is interesting, however, because it handles the repository work and does it in a completely transparent way. Considering the event-driven nature of Akka, this sounds fantastic. I am really curious about any trial&error there.

[Brian Hall]

Alexey, Did you ever do anything with Akka.net and CQRS/Event Sourcing? Curious because I have an upcoming project where I'm thinking of using these two together.

[Alexey Zimarev]

Not yet but I have plans for this year.

Basically, actors in Akka are persisted using event sourcing by default, when you use Akka.Persistence.

The CQRS is essential there since there is no reporting model available by default. Actors are by definition reside on the “write side” or “command side”. I have no strategy for this defined yet. If we go with Akka.Net, I will try implementing Akka.Persistence driver for @geteventstore. We have a working solution of using catch-up subscriptions and projections to create read models so this should work fine.

Vaughn Vernon gave a talk on using actor model and DDD on one pf the past years DDD exchange at SkillsMatter. I believe it was in 2014, when I left SkillsMatter after Greg’s course, one day before the exchange ;(

Regards, Alexey

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/H2RCQbAe068/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Ben Kloosterman]

I had a look at this and though it initially appears to fit well i doesn't fit  completely smoothly . Actors are independent micro services with read model included , you could  wrap many small domains.

Im not sure i like separating the read and write model into different actors though there are cases where this makes sense.eg collections..

I also looked at project Orleans and the new service fabric , its and great from a development time / maintenance point of view but not for high performance or distributed solutions.

--

[Alexey Zimarev]

Since I have no practical experience myself, I cannot argue right now :) But I will be meeting Vaughn on Tuesday and may be get some insights on this and his latest thoughts about using DDD with the Actor Model.

Though actors are independent services, they represent separate instances of certain type. As I remember, Akka was designed as the answer for the IoT emerging challenges. So this means that one actor holds its state but is not aware of other actors in any way except sending them messages. For me this means that I look at actors as long-living instances of aggregates, not as “services”.  In event sourcing aggregates are persisted by saving series of events, the sames happens with actors. In CQRS aggregates receive commands, command handler retrieves an aggregate from a repository, applies the command and the aggregate produces some events that when they are projected form a read model. Nearly the same happens with the actor model but the retrieval part is skipped and actors receive commands directly. The read model as understood by CQRS, is a “view” or “reporting” model, is not held inside an actor. The actor knows about itself. If you have ten thousands of temperature sensors, you will have ten thousand actors of the same type plus supervising actors and all other overhead of Akka, but essentially, sensor actors will work as individual aggregates keeping their state changed and the history of state saved in events. However, if you want to have to average temperature of some sensors based on their location or other criteria, you need a reporting model. Of course, temporal event queries and reactive patterns could solve some of the aggregation and IFTTT scenarios, this, as I remember well, is described in the Vernon’s boot “Reactive Messaging Patterns with Actor Model” and Greg gave some samples in his talk “Using Event Store as a read model”, but eventually, a cross-aggregate read model will be needed and this is where projections to some tables or document collections come to play anyway.

[Chris Sampson]

I have had a go at a domain with akka.net:

https://github.com/sammosampson/MessageRouteInspector/tree/Akka/Server

It may seem a little confusing at first as it is a domain for monitoring the movement of commands and events - a bit meta.

It uses event sourcing but only in memory as thats all i need for this. I found that actors work for handlers, aggregate roots and projections generally (most of my non root entities are not actors) .

Overall, I think it fits with DDD and ES very well, and its a very pleasant development experience. Testing is difficult - I do it outside in with SpecFlow, but use test actors that perform waits before returning results to help with taming its very asynchronous nature to fit with testing. 

PersonalIy, I prefer the decoupled message passing style of akka over the Orleans RPC style, Microsoft can't seem to let go of RPC!

[Peter Hageus]

I did a spike with akka.net a few months ago, but decided against it for now. There were a couple of reasons:

 

The storage abstraction does not work for the entire system. (no querying or catchup-semantics on eventbus, 1-1 view-aggregate, etc ).

 

Buffering and similar requires more boilerplate compared to something lower layer like RX.

 

I wanted more strongly typed restrictions for messages. (if I can get the compiler to enforce rules for me, I prefer that to writing unit tests)

 

Testing with preconditions required hacks.

 

Integrating with Task-based workflows introduced accidental complexity.

 

In the end I felt that all I got out of it compared to a handrolled approach was the concurrency model.  This might be very different for a technical domain though, and I do plan on using it in those areas later on.

 

/Peter