A única coisa que você pode fazer para ajudar a reduzir o impacto de uma mudança é dividir seu projeto geral em muitos componentes, de modo que, embora uma grande mudança tenha impacto em vários deles, muitos não serão afetados.
por exemplo, se o cliente decidir que precisa de um novo botão que envie dados por meio do intermediário para ser armazenado em uma nova coluna no banco de dados, você terá que alterar todas as camadas do sistema. No entanto, se o sistema também for dividido "horizontalmente", o impacto na interface afetará apenas parte da camada da interface do usuário, o restante não será alterado. Da mesma forma, se você tiver muitos serviços em sua camada intermediária em que cada processo processa determinadas partes dos dados, você só terá que alterar um deles - o restante não será afetado. o banco de dados também pode ser particionado em esquemas independentes.
Por exemplo, você precisa obter uma lista de usuários para ter um serviço que gerencia os dados do usuário. Quando você precisa obter uma lista de organizações também, você adiciona um novo serviço que lida com isso e mescla os dados juntos na interface do usuário (por exemplo), o que significa que você não teve que alterar seu código de acesso de usuário. Acho que esse tipo de abordagem é chamado de microservices , embora obviamente 'micro' não precise significar minúsculo, apenas logicamente separado .
Eu não tentaria introduzir abstrações, pois tudo o que acontecerá é que elas unirão suas camadas (por exemplo, uma alteração no banco de dados ainda exigirá a alteração da tabela subjacente, mas agora a camada DAL também precisará ser alterada e ter um DAL não vai necessariamente deixar você dividir o DB em seções, a menos que você tenha muito mais complexidade).