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 ? 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.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!