In the first post of this series we wondered how an application based only on Events would look like. To construct a proof of concept for this idea, in this second post we investigate data persistence under a different view.
Imagine a software application based only on Events. How would it be? And, what benefits that kind of architecture would bring?
With more and more people calling for banning algorithms from our lives, the truth is that algorithms do work. Is there an escape from this computational horror?
If narratives are just fiction, why do they matter? In this second part of the series, we explore our true nature as storytellers, and what happens when software application projects fail.
Fiction narratives lay in the core of software design. This first part in a series of two explores two examples: a narrative based on transactions, and a narrative based on Events.
Let's continue our exploration of the Domain and its representations in the code, we make a look into the timestream!
How can we make the most of the Domain-based methodologies to create software? The Domain Coach may a good answer to this question. But, wait, what is a Domain Coach?
If the Domain was a Universe, the vast collection of models that we create in our code to represent it would be a Multiverse.
Is software becoming so regulated, so expensive, and so important in our software-driven lives that the developer job is becoming not exciting anymore?
Is there a gift economy? Or, there are more unaverted connections among us that explain how free sharing yields economical value?
Architecture tests check that software keeps in full compliance of architecture decisions (or ADRs) after code changes were committed.
Here I propose Continuous Change, a new methodology for creating software with only one foundational pillar: never stop challenging our code, never stop changing our software..