How does this help me build maintainable software?
There are times when shortcuts make sense from an economic point of view. This chapter provided some insights into the consequences some shortcuts might have to help decide whether to take them or not.
The discussion shows that it’s tempting to introduce shortcuts for simple CRUD use cases since, for them, implementing the whole architecture feels like overkill (and the shortcuts don’t feel like shortcuts). Since all applications start small, however, it’s very important for the team to agree on when a use case grows out of its CRUD state. Only then can the team replace the shortcuts with an architecture that is more maintainable in the long run.
Some use cases will never grow out of their CRUD state. For them, it might be more pragmatic to keep the shortcuts in place forever, as they don’t really entail a maintenance overhead.
In any case, we should document the architecture and the decisions why...
