Author proposes software architecture speaks to its
use cases.> Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks.
We could still aim for a web app (client-server) or desktop app without mentioning Java Spring, Next.js, or Qt (yet).
> ... as a console app, or a web app, or a thick client app, or even a web service app, without undue complication or change to the fundamental architecture.
That speaks to Domain-Driven Design (DDD).
> A good software architecture allows [implementation] decisions... to be deferred and delayed
Somehow, we should be able to create an app in an absolute vacuum, with only standard libs and domain experts. Persistence, performance, and framework decisons can be maximally deferred.
The good thing is describing state machines up front. The bad thing is how to "split data structures," because it's hard to argue not to store everything in a database.
That also means test cases written without UI, with only business acceptance criteria allowed. Additional test cases would conform to the framework, end-to-end testing, and so on.
