Author proposes software architecture speaks to its <i>use cases.</i><p>> <i>Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks.</i><p>We could still aim for a web app (client-server) or desktop app without mentioning Java Spring, Next.js, or Qt (yet).<p>> <i>... 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.</i><p>That speaks to Domain-Driven Design (DDD).<p>> <i>A good software architecture allows [implementation] decisions... to be deferred and delayed</i><p>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.<p>The good thing is describing state machines up front. The bad thing is how to "split data structures," because it's hard to argue <i>not</i> to store everything in a database.<p>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.