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?
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.
Architecture tests check that software keeps in full compliance of architecture decisions (or ADRs) after code changes were committed.