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....
You must have heard these before: Bad programmers worry about the code. Good programmers worry about data structures and their relationships. — Linus Torvalds …Show me your data structures, and I won’t usually need your code; it’ll be obvious. — The Mythical Man-Month Smart data structures and dumb code works a lot better than the other way around. — Eric S. Raymond Of course, when dealing with software, it always depends but as a general rule I find these claims to be largely true....
I find it very unfortunate that there are so many negative experiences people have when attempting to implement Event Sourcing most of which turn out to be due to throwing too much infrastructure onto the problem, which as a general case doesn’t work most of the time in any context. What does this mean? You do not need an event-streaming platform like Kafka in order to implement Event Sourcing. (That comes later — if at all)....
Domain Event is a powerful modeling tool. From a technical perspective domain event is implemented as a simple immutable data transfer object, but conceptually, domain event is much, much more than that. Naming Domain Events There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton Naming domain events is no different, but if we understand the nature of a domain event, combined with a few useful guidelines, it is more than manageable....
By now, even the birds on the trees got the memo that microservices are not a catch-all magic pill that will fix all of your organizational and product issues seemingly caused by a monolithic way of thinking. More often than not organizations fail spectacularly by carrying over this monolithic way of thinking when decomposing their systems towards more decoupled (hopefully) microservices architecture and end up having even more issues and higher incurred costs as compared to the good old monolith....
For those that haven’t really moved past the blue book… DDD for many, including me, brought back the enjoyment of software development. Implementation becomes easy when you break down the domain. The bits and pieces suddenly start to “fit” together in a way they did not before, and the implementation itself becomes straight-forward which results in a simple, maintainable and easy to understand code that will outlive the development team itself....