
Link to presentation on YouTube:
I watch many software architecture talks (on-site and virtually), and I am starting to think that my understanding of software architecture differs from that of most speakers. I see a lot of talking about bounded contexts (as in Domain Driven Design), layers (as in Clean /Hexagonal/Onion Architecture), and dependencies (between classes, up-stream/down-stream contexts). Don’t get me wrong; these concepts are important. However, they are just a small part of all the aspects a software...
Onion, Hexagonal, Clean, or Fractal Architectures aim to organize how we deal with dependencies in our software architectures. But which one should we choose? After distilling the essence of each approach and comparing the advantages and challenges, I’ll show how to combine all of them into an approach to use evolutionary steps towards an architecture that fits your needs from day one until the software dies. You’ll see that layers and slices aren’t enough. A modularisation that fits the domain...
Evolutionary software architecture has gained much traction lately—at least in my bubble. It is one of my favourite topics, and I have presented and conducted workshops on it for over a decade. So, let me add a thought to the discussion:
The evolution of a software architecture has three dimensions:
Technical evolution,
conceptual evolution, and
the evolution of business capabilities
Bi-temporal event sourcing combines storing data as a sequence of events, which tell what has happened with the data, and the data has two associated points of time, one when the data entered the system and one when the data takes effect. This post is about our 8+ years of experience with bi-temporal event sourcing, along with code samples showing how to achieve this. Feel free to skip the code blocks and just read the conceptual parts. But you’ll miss the beauty of F# 😂 This post is part...