My 2 cents :

Als ontwikkelaar kun je naar mijn mening geen rekening houden met ieder punt in je ontwerp dat aan verandering onderhevig kan zijn.

Dat is per project ook verschillend. Als het een simpele asp.net site is die een aantal pagina’s heeft en waar wat flow in zit hoef je niet perse rekening te houden met schaalbaarheid en veranderingen.

Grote projecten daarentegen waarbij je ook in een grote groep gaat werken, kun je niet anders dan rekening houden met veranderpunten in je ontwerp. Maar goed daar is “loose coupling & tight cohesion” ook weer de vuistregel volgens mij.

Het boek “Design Patterns Explained” van Alan Shalloway en James R. Trott beschrijft dit ook min of meer.

And why is it that you have to put your 2 cents in, while it’s a penny for your thoughts? Somebody’s making a penny…

100% eens met je stelling dat je als ontwikkelaar rekening moet houden met verandering, ik zou dat echter graag wel willen scheiden in flexibiliteit in architectuur versus flexibiliteit in ontwerp. Hoewel de scheiding tussen deze twee vaak vervaagt, denk ik dat er binnen het kiezen voor een bepaalde architectuur (raamwerk, guidelines, constraints waaraan verschillende ontwerpen moeten voldoen) meer rekening gehouden moet worden met de door jouw genoemde ‘points of change’. Als er namelijk binnen ontwerp van verschillende delen door iedereen te veel rekening met verandering wordt gehouden loop je in de val van ‘generieke generiekheid’ ofwel ‘alles moet altijd overal kunnen’. Zo krijg je het recept voor een configuratie-hel danwel een minder gebruiksvriendelijke gebruikersinterface.

Mijn ervaring is dat als er binnen projecten gekozen wordt voor een duidelijke architectuur gebaseerd op separation of concerns ofwel het satelliet-domain model (http://www.domaindrivendesign.nl) je vrijwel alle flexibiliteit die je zal wensen - ook voor de toekomst - aan je project toevoegt.