O documento descreve uma estratégia de modernização arquitetural incremental em 3 estágios: (1) o novo sistema depende do legado através de uma camada de transição, (2) parte do legado é refatorada e incorporada ao novo sistema removendo a dependência, (3) o legado é completamente desativado após toda a refatoração.
4. ESTRATÉGIA DE CONVIVÊNCIA
Paraserpossívelimplementaraarquiteturaalvodemaneiraincremental,comprojetosdecurtoprazo
alinhadosaumajornadaplurianual,háquesedefinirumaestratégiaondeolegadoconvivacomo
novo,semcorrompe-lo.
Estágio 1 – Novo dependendo do legado
O legado está desestruturado e não oferece uma interface clara de integração.
A nova solução prevê construir algo novo em convivência com o legado, para futuramente
substituir parte dele e, então, todo ele.
Ao invés de a nova solução acessar o legado conforme o nível de abstração (interface) que
ele oferece, ela vai acioná-lo já no novo nível de abstração (no esquema, “MS 2”).
O legado é incapaz de se comportar no novo nível de abstração e, nesse cenário hipotético, a
funcionalidade legada não pode ser imediatamente recortada para a nova arquitetura
(exatamente para viabilizar uma implementação incremental).
É construída, então, uma camada de transição que corrige as “imperfeições” do legado e é
acionada como se já fosse o “MS 2”.
A nova arquitetura, desta forma, convive com o legado sem ser contaminado por ele.
5. ESTRATÉGIA DE CONVIVÊNCIA
Estágio 1 – Novo dependendo do legado
O esquema que segue ilustra arquetipicamente como se alcançar tal objetivo:
6. ESTRATÉGIA DE CONVIVÊNCIA
Paraserpossívelimplementaraarquiteturaalvodemaneiraincremental,comprojetosdecurto
prazoalinhadosaumajornadaplurianual,háquesedefinirumaestratégiaondeolegadoconvivacom
onovo,semcorrompe-lo.
Estágio 2 – Ponto de dependência refatorado
Num projeto (ou sprint) futuro, a parte não estruturada do legado da qual dependia a nova
solução será agora restruturada (fará parte do novo).
A antiga estrutura ficará agora encapsulada no “MS 2” da nova arquitetura.
Não há mais dependência fortemente acoplada do novo para com o legado (ex: pode se tratar
de uma simples replicação de dados)
As funcionalidades legadas acessadas pela aplicação anterior (a “Tela 1”) são desativadas e
agora fazem parte da “SPA 1”
Os módulos da camada de transição são excluídos, sem que a nova solução (“Controller 1”)
sofra qualquer impacto, ou seja, ela acessa a mesma interface (API) através do mesmo
endereço (URI).
7. ESTRATÉGIA DE CONVIVÊNCIA
Estágio 2 – Ponto de dependência refatorado
O esquema que segue ilustra arquetipicamente como se alcançar tal objetivo:
8. ESTRATÉGIA DE CONVIVÊNCIA
Paraserpossívelimplementaraarquiteturaalvodemaneiraincremental,comprojetosdecurto
prazoalinhadosaumajornadaplurianual,háquesedefinirumaestratégiaondeolegadoconvivacom
onovo,semcorrompe-lo.
Estágio 3 – Legado desativado
Uma vez que todo o escopo da aplicação legada foi refatorado, ela é desativada.
Quaisquer interfaces entre o sistema (legado ou novo) com outros sistemas continuam
preservadas (a não ser que sejam também objeto de refatoração).
Da mesma forma que se trata convivência durante a refatoração/reconstrução interna de uma
aplicação, pode-se adotar essa abordagem também para a refatoração entre aplicações.
Nesse caso, há que se criar módulos inteiros de transição que sejam capazes de traduzir
interfaces de integração novas em interfaces de integração antigas.
Uma vez que os novos sistemas sejam substituídos, os módulos de transição são desativados
da mesma forma.