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 this eg. http.HandlerFunc). I employ this approach often and I figured it wouldn’t hurt to share it. Where does this come from?...
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)....
Hexagonal / Ports and Adapters architecture in insert your language here How many of these have you seen before? Probably too many, but I promise, this will be a short one… Why another article? First, I have a confession to make. I have had this article in my backlog for at least four years now but have never “gotten around” to finishing it due to numerous reasons (the biggest one me simply being lazy)....
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....
It is very hard to reason about life, death, nature of existence, and reality itself. Eternity/Infinity are hard concepts to grasp. Even all religions have the promise of eternity (once you die) and most of them claim that “God” himself is eternal. For an ordinary human, it is really hard to grasp those concepts. Or is it … Most of the difficulties related to that lie in the fact that w most of the time we are looking at it from the wrong frame of reference....
Design patterns are very useful things in general and they pop up a lot if you are applying DDD in an OOP context (If you’re there you are probably already applying Tactical DDD patterns). One principle I want to emphasize here because I see so many violations of it, is the following: Don’t use pattern names when implementing a pattern. It’s amazing how people keep missing the point. Applying this principle is actually very helpful in double checking if you are applying the right pattern to the right thing....
When talking about software, we often hear the term “architecture” mentioned a lot. That inevitably reminds us of buildings and construction. While this may be true up to some extent, there are a lot of discrepancies between the approaches we take towards architecting a building (a house for example) and a typical web application software system. Much more so if we employ agile practices while doing so (which I hope we all do)....
When talking about Domain Driven Design, the thing we hear most often is that it’s about the software being guided by the domain, which is true, but I argue that it’s just one side of the coin and cannot stand alone. The other less emphasized aspect of it is the one where you actually try to understand the problem that the domain is trying to solve, it’s where you push back, challenge the status quo, try to understand the domain/problem itself and model towards first principles....
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....