aecor VS Clickhouse-scala-client

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 library, 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 close to DDD & Akka nomenclature as much as possible. All in all I'm confident as it's lightweight and there is no magic, we simply delegate to Akka's DSL, we're not re-implementing an actor runtime. The main value in this approach IMO is the separation of concerns: it allows lean and expressive description of the domain, while retaining precise wire protocol handling in the infra layer. We also introduced some cool abstractions to manage side-effects and control passivation explicitly. The downside could be that tagless final isn't necessarily easy to bootstrap in a codebase when you're not used to it. But what I found it is that 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 is easy to read and replicating the patterns isn't so difficult. Where it gets a bit fancy is with 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 . 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!