I've become a big fan of not worrying about architecture until the rewrite. The first version is always an exploration of the problem domain, and treating it as that has always made my projects go quicker. This is going to trigger some people, so here's some caveats: - there's always a rewrite. Even with perfect architecture. Usually because nobody understands the problem domain until there's been an exploration of i…
(Belated response, sorry. Reviewing my comments and replies received.)
Applying Use Cases deeply influenced me. TLDR: Architecture is derived from use cases.
https://www.amazon.com/Applying-Use-Cases-Practical-Guide/dp...
At the time (of the 1st edition) I was still doing UI. Stuff like direct manipulation graphic design apps. Basically domain specific knockoffs of Illustrator.
I call this strategy "outside in architecture". (I'll have to read the book again to see if I stole that phrase.) Whereas pretty much every other dev I've ever worked with started with the building blocks and worked towards the user.
Per the book Design Rules: The Power of Modularity, architecture is the visible interface of a system, and all the design choices captured by that interface. In other words: What the user (client) sees. Even though I now do mostly services and backend stuff, I still have a user interface designer's sensibility. Where I figure out how something should look and feel before figuring out how to implement it. (There's still an iterative back & forth dance, of course.)