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..
I consider the aversion to change that monoliths exhibit as their defining feature. And the benefits of embracing change in organizations based on software are explored.
According to their fundamental different features, master entities and transaction entities are defined, and a different location in the layers of an hexagonal architecture is proposed.