Thanks, and thanks for your question!
So regarding production use I wish I could tell you that we have load on a service using this, but as of just now it's not the case. It's recent and we're using this in a new micro-service which is not seeing much load yet. However this builds up on experience we've had dealing with Akka clusters for the past three years or so.
We've been trying to find a way to have a lean and expressive domain while retaining Akka's power for a while, we actually published this article a while back where we were still using an OOP approach.
Then we found out about a cool library, https://github.com/notxcain/aecor , which was going full FP with the domain. However, we could not use the library directly for a number of reasons, chiefly because we are attached to keeping the layer above Akka as lightweight as possible and we want to keep a tight control on serialization aspects for rolling deployment. There also are other more differences: for instance we consider command rejections as first-order values, therefore opting for Either for replies. In endless, we’ve also tried to stick to close to DDD & Akka nomenclature as much as possible.
All in all I'm pretty confident as it's lightweight and there is no magic, we delegate to Akka's DSL actually, we're not re-implementing an actor runtime. Regarding threading everything's still taken care of by the Akka pool as we define a custom cats effect IORuntime at the app level.
The main value in this approach IMO is the separation of concerns: it lets you be pure and expressive in the domain, while retaining "dirty but precise" wire protocol handling in the infra layer.
The downside is maybe that tagless final isn't necessarily easy to bootstrap in a codebase when you're not used to it. But if someone with experience or time to experiment bootstraps the project, it's not so difficult to get the others on-board afterwards, since the domain becomes easy to read and replicating the patterns isn't so difficult.
Where it gets a bit fancy is the usage of natural transformations internally, for which we rely on cats-tagless. That requires annotating traits involved in entity behavior with `@autofunctorK`. This also prevents us to go to scala 3 for now as `cats-tagless` is blocked on some missing macro feature in scala 3 apparently.
The project has a functional sample application that you can play with so that you can get a feel of how it looks in practice. If you do, make sure to let me know how it goes and if you have further questions!