Of course “it depends” — all abstractions are constantly wrong in a way (there are no correct models only useful ones) and we iteratively try to make them “less wrong” over time. …

Modules, SOA, Microservices, Macroservices, Microsystems, Monoliths… — If we haven’t identified proper system boundaries, none of these concepts and/or approaches matter. Too often do we jump into technical jargon and start dissecting our monolith or even worse start of with a distributed system without actually understanding the problem space we are dealing with. Without proper understanding, I’d…

I spent a few weekends polishing the LeanBoard and introducing the initial forms of two of most important features which are: - live collaboration (just share the link) - local persistence (your bards are saved locally) There is still no server backup so the boards will only exist on all personal machines, but this is coming soon. As everything else collaboration still has some rough edges but I can say that it is already quite useful as a package.

It is no secret that I am a big fan of Event Sourcing and consequently Event Storming and Event Modeling. Although most of the time when doing it online or alone, I love to use Miro, I must admit that I have always longed for something more simple and “real-life-like”…

Hello Gerard, In fact I do agree with you and I fail to see where we disagree actually. "I don't agree with you that event sourcing, is just storing all the events forever" - I didn't actually make such a statement "Event sourcing would need at least also the following…

Very detailed and straight to the point article as always. A couple of months ago I wrote a similar although very small post as a response to a comment I made elsewhere: https://blog.devops.dev/event-sourcing-is-not-event-streaming-960963c5d6d5 Antons post goes into more details and gives more detailed reasons why Kafka is not a good fit for ES. I would argue though that it is not impossible to implement a limited niche event sourcing solution by using single partition topics in combination with kafka transactions and compacted topics (eg. you would always snapshot) - but this is far from ideal and would be of very little use except in very very small niche cases.

I like functions, especially higher-order ones and I think we often underestimate their power when working with Go. More often than not, we jump to creating a type and attaching a method to it when maybe a simple regular or higher-order function would do (standard library surely, makes use of…

Hi Anton, As a metter of fact, I have read quite a few of your articles and they resonate quite well with me. …

Not long ago I have slowly started preparing material for a pragmatic hands-on book I’ve always wanted to write on the topic of event sourcing, where I would explore it in my own approachable way, applicable to any skill level while also spicing it up with golang, ports and adapters, tdd, testing, event driven architecture and good software engineering practices in general. It’s still early days and I am still fleshing it out. I would be grateful if anyone that is interested in any of these topics would reach out to me with any suggestions regarding specific topics you would like covered etc…