I agree with you it's tough to sell CQRS, it's like trying to explain to someone that their business should use a database in one line.

For me event-sourcing is a historical layer below your existing database that allows you to replay the sequence of events that got your database to its current state.

If I had to businessify it, maybe it would be 'Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again.'

From a technical perspective, engineers can focus on the product and organically build and destroy the data structures around a changing business instead of trying to find the perfect data-structures that will inevitably be incorrect as the business grows and evolves. You get regression tests for free, and you get backups for free which may be nice-to-haves when the business is small, but absolute requirements once you have real customers paying real money. Not sure how I would squeeze that in an elevator pitch though.

Greg Young's presentation on event-sourcing is pretty great, you may find some inspiration there:

https://www.youtube.com/watch?v=JHGkaShoyNs

PS: I like "Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again." :-)

Thanks for the idea!

This was my end goal. A better one liner for you. This one liner works for me as a programmer. And I'd venture to say most business people would get it too.

"For me event-sourcing is a historical layer below your existing database that allows you to replay the sequence of events that got your database to its current state."

In other words, a transaction log.

Yeah, that's essentially what it is. For example, you can build event-sourcing by tapping in to the log-shipping facilities that postgresql offers (set wall to logical, and assign a replication slot to it)

A transaction log is too detailed and specific. Typically an event log lists actions from the business domain rather than what got affected. It should explain what happened, not how it happened.

Great explanations that avoid too much jargon and that I think most developers could understand. Your one-liners and more detailed explanations got me hooked, and I want to know more. This is the right way to do it. Thanks!

What might also be interesting is https://www.youtube.com/watch?v=rolfJR9ERxo

That's so much better. Now I know what it does. I know whether or not to read on. But I would also throw a benefit or two in there. Why should I use a framework (or your framework specifically) if I want to build a scalable API that uses historical data?

And the next step is putting your one-liner everywhere that people first come across your product. On your website main page, and especially at the beginning of blog articles.

I guess this is becoming enough of a pet peeve of mine that I should write about it myself and give examples of good vs. bad and why to do it.

Well, the point here is: The reason why you should use it, because of the benefits of CQRS and event-sourcing – and unfortunately, at this point, I think you need to get your feet wet and learn about these concepts ;-)

Maybe https://docs.wolkenkit.io/3.0.0/getting-started/understandin... is a good place to start.

> The reason why you should use it, because of the benefits of CQRS and event-sourcing

So this is the ONLY framework that provides an implememtation of CQRS and event-sourcing? What I was trying to get at is to try to tell me why you're different and better.

None of this is easy. One-liners are very hard to get right. But it's worth the work.

It is the only one (I know of) that provides an all-in-one integrated approach that "just works".

Actually, inspired by your comments, I'm currently sitting at my desk, thinking about how to improve the claim.

I would love to discuss things with you. If you are interested in exchanging ideas as well, feel free to contact me via mail ([email protected]).