Com passar per alt els sistemes d’estats i esdeveniments (i vèncer el goril·la)

Teniu un nou sistema CQRS brillant, està completament desenvolupat i esteu a punt de començar la prova d’integració. I el goril·la de 800 lliures que va dormir al racó durant les discussions del vostre domini s’està despertant.

Sense fer una ullada als vostres diagrames de domini complets, històries d’usuaris interessants, models d’interfície d’usuari o criteris d’acceptació ben documentats, es trenca el “límit contextual” que hauria de retenir.

El goril·la s’enfonsa pels edificis, destrossant el valor, arrencant els agregats i generalment destruint qualsevol consens sobre el projecte. Gorilla, el teu nom és Legacy Integration.

Hola nois! No puc esperar per veure com la vostra aplicació de microservei RESTful s’integra amb aquest sistema ERP a mida de 30 anys. Espero que us agradi COBOL. (Cortesia de

La integració de sistemes i processos heretats pot aturar un projecte d'una altra manera perfectament executat. És una migranya monstre d’un problema que només s’ensenya a l’escola de cops forts. Aquest també és un problema que afrontareu com a desenvolupador (si encara no ho heu fet) quan treballeu amb empreses i dominis consolidats.

Per descomptat, si teniu sort, no haureu començat a codificar (o almenys és aviat en el procés) quan es desperti el goril·la. O si ets intel·ligent, veu el goril·la amagat sota la pantalla de la cantonada i frega les cicatrius del darrer encontre per evitar l’inevitable embolic incorporant-lo a la teva arquitectura des del principi.

Tractament de sistemes heretats

Com a subdirector arquitectònic de l’Oficina de sistemes d’informació de la investigació de l’UCLA, sóc responsable de tancar moltes mancances de sistemes i dades. UCLA té una sèrie de processos i sistemes empresarials de dècades de recerca que van en contra de qualsevol intent de "pertorbar" aquests enfocaments tradicionals amb les noves tecnologies.

El més aterridor és que aquest oleoducte s’omple amb algun que altre iceberg impenetrable de dades heretades que sovint requereix una disputa en temps real.

Oh Déu meu! Una muntanya de dades! No, espera, això és només un Fatberg. M’alegro d’haver escollit una carrera en matèria de codi en lloc d’higiene. (Crèdit de la imatge: The Associated Press)

A la meva oficina, la nostra tasca és garantir la integració a aquests sistemes heretats a un ritme creixent. També estem ampliant els nostres sistemes de transaccions a mida per gestionar processos de petites empreses.

Per als nostres propis sistemes, generalment seguim el patró de microservei. Integrem més complexitat si cal, p. B. Disseny basat en dominis (DDD) i proveïment d’esdeveniments. El nostre major repte per a aquests sistemes és la integració de sistemes heretats en sistemes de persistència estatal.

Aproximació a la integració

En els propers paràgrafs, explicaré el nostre enfocament. D’aquesta manera, hem abordat un dels problemes derivats del pont d’un sistema d’esdeveniments, particularment d’un sistema d’esdeveniments híbrids, a un problema purament estatal.

Un principi important que els implementadors solen passar per alt és que el proveïment d’esdeveniments no s’hauria d’aplicar a tot arreu. Això és segons Greg Young, a qui se li atribueix àmpliament la introducció del patró d'arquitectura de programari de "proveïment d'esdeveniments".

Utilitzem proveïment d’esdeveniments als nostres sistemes per tal de complir requisits específics i específics. De vegades, això provoca que les nostres aplicacions estiguin fora del flux d'esdeveniments. A més, alguns dels nostres activadors d'esdeveniments es deuen a canvis d'estat poc fiables al sistema d'origen. Això requeriria molta correcció d'esdeveniments post hoc i "rebobinar-rebobinar" si només depenguéssim del flux d'esdeveniments.

Una solució escèptica

La solució que hem trobat a això és el que anomeno "subscriptor escèptic". El subscriptor escèptic aborda el problema de la "poca fiabilitat" del costat de l'esdeveniment del sistema, almenys des de la perspectiva de la màquina d'estat heretat. També es tracta de sistemes on la generació d'esdeveniments pot fallar a causa de problemes amb dades anteriors:

  1. La font d'esdeveniments pot generar esdeveniments que no condueixen a canvis d'estat que siguin rellevants per a la màquina d'estats heretats. Des del seu punt de vista, es tracta d'esdeveniments "falsos positius"
  2. És possible que la font d'esdeveniments no pugui generar esdeveniments per als canvis d'estat rellevants per a la màquina d'estats heretats. Des del seu punt de vista, es tracta d'esdeveniments "perduts" o "saltats"
  3. És possible que no es generin esdeveniments a causa d’errors o errors a la font original de l’esdeveniment. Això passa especialment en els fluxos ETL (Extract-Tranform-Load) de repositoris de dades antics. En tots els aspectes, es tracta d'esdeveniments realment saltats

L’enfocament dels subscriptors escèptics tracta aquestes preocupacions desconfiant del flux d’esdeveniments. El flux d'esdeveniments es tracta com a possible activador o notificació que l'estat ha canviat, però també s'accepten altres possibles activadors. També desconfia de la precisió dels informes de canvi d’estat.

Tan bon punt es notifiqui al participant que l'estat pot haver canviat, notifica una passarel·la d'estat que consulta l'estat del sistema basat en esdeveniments.

Aquesta passarel·la d'estat avalua l'estat en funció de l'últim estat conegut (tal com el coneixia el sistema de subscripció).

Si el canvi és rellevant, actualitza l'estat del sistema de subscripció i, si cal, inicia els processos comercials associats del sistema de subscripció.

Ladies and Germs, el subscriptor escèptic!

Alguns requisits

Per utilitzar aquest enfocament, el vostre sistema de subscripció ha de:

  1. Els atributs d'estat en qüestió ja persisteixen del sistema de recuperació d'esdeveniments o es poden derivar del que fa?
  2. Permeteu fer el mateix que enganxar de nou les dades del canvi d'estat

El vostre sistema d'abastament d'esdeveniments ha de:

  1. Proporcioneu un servei de consulta que representi de manera fiable l’estat del sistema i que contingui tots els atributs d’estat que requereix el sistema subscriptor
  2. Incloeu prou dades al flux d’esdeveniments per trobar els registres rellevants al servei de consulta
  3. Admeti una "llista" o una altra consulta per lots del servei de consulta

El subscriptor escèptic que implementeu ha d'incloure:

  1. Una passarel·la d'estat que pot consultar el servei de consulta per a un conjunt de dades específic (basat en esdeveniments) o per a una llista de conjunts de dades (un altre activador per recuperar els esdeveniments "perduts").
  2. La passarel·la d'estat ha de contenir una lògica de comparació de dominis del context del sistema de subscripció que descarta els registres si no han canviat respecte al domini de subscripció
  3. Una implementació de subscripció a esdeveniments per invocar la passarel·la per registre dels esdeveniments
  4. La possibilitat d’actualitzar la capa de persistència del sistema de subscripció amb els canvis (de manera que el mateix registre no es torni a actualitzar la propera vegada), p. B. mitjançant un dipòsit

El subscriptor escèptic també pot implementar l'inici de processos empresarials al sistema de subscripció.

Si només és un estat, es pot fer mantenint nous registres de processos per iniciar els processos associats. En cas contrari, es pot trucar a l'API del procés exposat.

Quan inicieu aquests processos empresarials, també heu d'implementar el bloqueig a la passarel·la per no duplicar la iniciació del procés si es produeix un activador d'esdeveniments durant el procés ETL.

Resultats positius

Hi ha molts altres reptes associats a la integració de sistemes heretats, especialment quan es canvia entre contextos relacionats amb els esdeveniments i els relacionats amb l’estat. Tanmateix, aquest patró ens ajuda a minimitzar les despeses tècniques associades al manteniment d'esdeveniments a mesura que es consumeixen herències (i dades irregulars).

Abans de seguir aquest patró, treballàvem estrictament orientats a esdeveniments. No vam tenir accés ràpid a les opcions d'assistència que ofereix un estat editable directament. Amb aquest patró hem recuperat aquestes possibilitats. Si el sistema heretat es comporta malament perquè no li agraden els esdeveniments que està rebent, hem canviat la càrrega de canviar el flux d'esdeveniments a canviar simplement d'estat.

També hem afegit una capa d’acoblament fluix per protegir generalment el sistema de subscripció del contacte directe amb esdeveniments. Això permet redireccionar altres activadors del sistema participant.

Per exemple, un ETL antic pot actuar com a activador de passarel·la per a l'estat inicial fins que estigueu a punt per canviar a un flux d'esdeveniments. I això sense complicar el servei CQRS mitjançant la implementació del subscriptor escèptic intersticial com a unitat independent.

Aquí teniu un consell per al científic de dades i els tècnics que les operen: quan implementeu la persistència de políglotes al dipòsit de subscripció, també podeu crear un magatzem de documents que filtrarà automàticament els canvis de dades que reflecteixin un procés comercial significatiu.

En cas que "es salti" o es perdi un esdeveniment, disposem d'un canal d'assistència senzill. O bé notifiquem de nou al subscriptor sobre aquest registre (si sabem quin registre ha perdut un esdeveniment) o fem una pregunta de "recuperació" per a tot el sistema (si no n’estem segurs).

Ho podem fer sense haver de tocar el flux d'esdeveniments. Això vol dir que l’activitat de suport no afecta les altres aplicacions de subscripció.

Pensaments finals

No és per a tots els problemes (o fins i tot per a la majoria de problemes). Però és una excel·lent solució per aprofitar l’acoblament solt i altres avantatges derivats de l’aprovisionament d’esdeveniments i CQRS, alhora que minimitza la sobrecàrrega de suport per a la resolució de problemes de fluxos de dades heretats. Això permet als nostres desenvolupadors dedicar més temps a escriure noves aplicacions i afegir valor als nostres clients.

Si us ha agradat aquest missatge, feu clic al botó següent i clameu-me unes quantes vegades perquè hi vegi més gent. Moltes gràcies!

Jonathan és subdirector d'arquitectura i operacions de la divisió de sistemes d'informació de recerca de la UCLA. Després de graduar-se a la Universitat de Stanford amb una llicenciatura en física, va treballar durant més de deu anys en les àrees d’arquitectura de sistemes d’informació, millora basada en dades de processos de negoci i gestió organitzativa. També és el fundador de Peach Pie Apps Workshop, una empresa centrada en la creació de solucions de dades per a organitzacions sense ànim de lucre.