Cred că problema nu este, că de exemplu se folosește componente symfony pentru drupal 8 sau că pentru magento 2 s-au adoptat anumite standarde, ci faptul că în locul codului vechi s-au cuplat la un framework și la un model de tip crudish.
Dacă în schimb, pentru un modul nou, mai înainte de a scrie cod, se face o minimă analiză, de genul 3 amigos (developer, tester, business) și din care să rezulte niște scenarii care sunt formulate într-un limbaj înțeles de toată lumea, fără referințe la ui sau alte detalii de implementare și care exprimă work flow-ul de business.
Astfel, de exemplu după ce ai făcut modelling by example poți avea pentru un client ce are 2 magazine pe platforme diferite de magento, aceiași funcționalitate în core, urmând doar să scrii codul de connectare la platforma respectivă pentru fiecare caz în parte, sau poate în cazul unui csm ca și drupal 8, upgrade-ul la o nouă versiune sau chiar schimbarea la un alt csm de exemplu eZ Platform, se poate face ușor pentru că core-ul este separat, ducând spre o arhitectură de tip hexagonal.
Asta ar fi soluția pentru sisteme legacy, de tip database first, adică de fapt a modului în care se face stocarea pentru schimbarea stării unui concept.
Mai greu ar fi, pentru astfel de sisteme, ca noile module să utilizeze o arhitectură de tip event sourcing poate după o sesiune de tip event storming pentru că probabil integrarea nu ar fi la fel de lină, dar care cred că ar merge de minune pentru ceva nou și care nu depinde decât de php, eventual un framework pentru cqrs/es în php.