Introdução
A restrição já está posta pelo artigo: a Lei da Mudança Contínua de Lehman (1974) — todo sistema em uso real será solicitado a mudar, indefinidamente, e a única pergunta em aberto é se essa mudança sai barata (alteração localizada) ou cara (reescrita). Os três princípios desse cluster não impedem a mudança — não tem como impedir que ela chegue —, eles atacam a fonte de onde ela vem, cada um numa direção diferente: #8 blinda contra mudança que vem de fora do sistema (o ecossistema de frameworks), #11 blinda contra mudança que vem das pessoas ao redor do sistema (atores com pedidos concorrentes), e #9 blinda contra mudança que vem do próprio domínio crescendo além do que foi validado como seguro.
#8 Distância do Framework
A base conceitual é o que Robert C. Martin ("Uncle Bob") formaliza em Clean Architecture (2017): frameworks pertencem ao anel mais externo da arquitetura — são um detalhe de entrega, não o centro do sistema. A regra de negócio não deveria importar nada do framework; é o framework que deveria se adaptar pra rodar a regra de negócio (a Inversão de Dependência aplicada em escala arquitetural, não só entre duas classes). Martin propõe um teste simples pra isso, conhecido como "screaming architecture": olhando só a estrutura de pastas de um projeto, ela deveria gritar o domínio do negócio — "isso é um sistema de compliance fiscal" — e não gritar o framework — "isso é um projeto ASP.NET" ou "isso é um projeto Angular".
