Article about DDD with Akka Typed Persistence

Akka Libraries
1

Hi there!

I’m working on a blog article that describes some abstractions for domain-driven event sourcing, built upon Akka Typed: https://github.com/jchapuis/akka-persistent-entity

I thought that this could be a useful piece of information for anyone who’s looking for guidance in building akka-typed persistence systems with a pure domain layer. What do you think?

Cheers!

Jonas

4 Likes
2

What do you think?

I think that we have a Lagom Persistent Entity for this. Am I missing something?

3

One of the core tenants of DDD is to keep the domain as pure as possible. As Andrzej Ludwikowski is also saying in his good article, mixing persistence code with domain code should be avoided, and the domain should not be coupled to a particular technology, even one as awesome as Akka :grinning:

So the approach described in this article illustrates how to achieve an agnostic domain and separation of concerns with some simple abstractions, that still took us some time to elaborate and as such could be worth sharing (maybe in some related links page in the docs, if such a page exists). We’re working on a medium publication for it, I’ll post the link here when it’s ready.

1 Like
4

Thanks for sharing @jchapuis

One of the core tenants of DDD is to keep the domain as pure as possible.

We have some samples in the docs where we separate the domain logic as far as possible from the EventSourcedBehavior APIs (Style Guide • Akka Documentation), the commands, events, state and event handler only deals with domain specific classes but you cannot define the command handlers without using the Effects API and tying that to Akka persistence.

I’d argue though that creating your own duplicate effects API just to then translate to the Akka one sounds like a waste of time and complexity in the name of maybe-well-switch-tech to me, especially if it becomes its own little event sourcing framework on top. Maybe I’m missing something there, or I’m just too much of a pragmatic (and biased being in the Akka team). :)

5

Thanks for your reply @johanandren. Yes, you guys did a really good job on this persistence API and DSL, it’s already very expressive. The abstractions we’re describing in the article are very light, they don’t do much more than capturing our main usage flow (command -> command validation -> event generation -> even persistence -> event-application).

We’re not really doing it to be able to switch to a different tech actually, who would move away from Akka :grinning:? Still, we find this approach has some advantages:

  • Testing the domain behavior is easy because it’s just some functions with plain types
  • Even though the DSL is expressive, most of our entities follow the same flow so akka plumbing calls like Effect.reply, Effect.persist etc. aren’t really needed to the description of the domain - we thus gain some “noise” reduction. When entities become big with a lot of commands, replies, handlers, any code reduction is a boon.
  • From an architectural standpoint, all entities using this abstraction will follow the same pattern. So it sorts of “drives” us into doing the right thing, and makes understanding the system as a whole easier. We know all entities behave with the same flow, without special side-effects for instance. If there are exceptions, they stand out because they would use the DSL directly.
  • We can also make adjustments to that common behavior which will benefit all the services, and following future evolutions of Akka API is simple, it’s all located in one spot.

But once again these are very small abstractions. The typing was a bit tricky to figure out though so we still felt this was valuable to share!

2 Likes
6

For those of you who are interested, we have also just published this in the medium format: https://medium.com/bestmile/domain-driven-event-sourcing-with-akka-typed-5f5b8bbfb823?source=friends_link&sk=886a96bee509462ed2281fce8b129d9a

1 Like