3 ms·

Love how the "Getting Started" to Wolkenkit doesn't even have any tangible code until page 3. If your quick start guide can't even get to the point until halfwa

Love how the "Getting Started" to Wolkenkit doesn't even have any tangible code until page 3. If your quick start guide can't even get to the point until halfway down the page, I'm gonna bet that your framework isn't very user-friendly. Also, can anyone tell me what this even does? I've been clicking around and besides a bunch of vapid "philosophy" documents I can't figure out what the fuck anyone would use this for...

akiselev 8y ago
As others have said on this page, event sourcing is one of those technologies where if you don't know what it is, you certainly don't need it. Even if you do know what is, you usually don't need or want it unless you have no choice. In event sourcing, instead of having stateful objects, you have a log of events that you use to build that state. It gives you powerful rollback, backup, and history features at the expense of some insane code complexity (usually solved by tooling). When paired with CQRS, another architecture separating reads and writes in your abstractions, and done well with events that are domain oriented ("AccountingReconciliationStarted" instead of "StartButtonClicked"), you can hide most of the code complexity and allow developers and less technical users to focus on domain complexity (i.e., the logic that matters to the real world). At least in theory.
- elcritch 8y ago
  Why the insane code complexity? Yes there can be a lot of complexity in storing the events but using Kafka or similar event stores which provide libraries for handling the connection details should remove most of that complexity. Then your code can essentially be written as a map-reduce. Add a stream filter and it can easily be transformed to/from a Redux event system to a business one. Perhaps if your codebase didn’t build on a streaming architecture it would necessitate a lot of advocacy code.

akiselev 8y ago

As others have said on this page, event sourcing is one of those technologies where if you don't know what it is, you certainly don't need it. Even if you do know what is, you usually don't need or want it unless you have no choice. In event sourcing, instead of having stateful objects, you have a log of events that you use to build that state. It gives you powerful rollback, backup, and history features at the expense of some insane code complexity (usually solved by tooling). When paired with CQRS, another architecture separating reads and writes in your abstractions, and done well with events that are domain oriented ("AccountingReconciliationStarted" instead of "StartButtonClicked"), you can hide most of the code complexity and allow developers and less technical users to focus on domain complexity (i.e., the logic that matters to the real world). At least in theory.

elcritch 8y ago
Why the insane code complexity? Yes there can be a lot of complexity in storing the events but using Kafka or similar event stores which provide libraries for handling the connection details should remove most of that complexity. Then your code can essentially be written as a map-reduce. Add a stream filter and it can easily be transformed to/from a Redux event system to a business one. Perhaps if your codebase didn’t build on a streaming architecture it would necessitate a lot of advocacy code.