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.)
I always try to explain to startups that they don't understand the problem until they've built the first version and launched it, and until they understand the problem they can't spec an architecture to solve it.
(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.)