Dietro le quinte
Ecco il nostro stack tecnologico
di Nicolas Lefebvre
I nostri architetti senior sono orientati al dominio
27.10.2020
Sono temuti in tutto lo sviluppo del software di Digitec Galaxus e si chiamano Team Q. Stiamo parlando dei nostri cinque Architetti Senior. Tuttavia, la loro vita quotidiana non è caratterizzata solo da analogie con James Bond, ma anche da aria calda, burro e Kafka. E stanno cercando un altro membro dell'equipaggio.
Q, una lettera che attualmente viene utilizzata spesso. Alla Digitec Galaxus, tuttavia, non è per via dell'ambiguo impiegato governativo americano. Il Team Q prende il nome dal competente specialista informatico con senso dell'umorismo dei più recenti film di Bond. Q è l'associazione dei cinque architetti senior di Digitec Galaxus, noti internamente come Domain Architects. Il nome dice tutto: Il team lavora secondo i principi del domain-driven design per dividere il nostro sistema software nei cosiddetti contesti. Ad esempio, c'è il contesto che si occupa dell'acquisto del nostro assortimento o quello della logistica delle merci in uscita. Il vantaggio: se uno sviluppatore lavora nel contesto delle merci in uscita, può essere relativamente sicuro di non modificare la logica degli altri contesti. Se si apportano modifiche alle interfacce, si consiglia di fare attenzione. Nel caso di modifiche generali, le interfacce aiutano a valutare quali altri contesti sono interessati.
La migrazione del nostro precedente sistema monolitico in esecuzione su Azure con poco più di 2 milioni di righe di codice C# .Net e un database SQL con 1700 tabelle a un sistema distribuito che ospitiamo su Kubernetes ha caratterizzato la vita quotidiana del Team Q per diversi anni. Chiamiamo questo processo "modularizzazione". Nell'immagine attuale, il sistema è suddiviso in circa 40 unità integrate verticalmente e basate su modelli di microservizi. Un team di sviluppo è responsabile di ogni unità, che contiene uno o più contesti.
Il team Q è distribuito spazialmente nell'intero reparto di sviluppo software. Tuttavia, il "sit-down" settimanale (in contrasto con lo "stand-up" (o quotidiano) dei team di sviluppo) è un punto fisso del programma. C'è ancora qualcosa di misterioso nel Team Q. Ora stiamo cambiando questa situazione: ti mostreremo chi c'è dietro Q e su quali aree stanno lavorando gli architetti senior.
Area shop online
Andreas - esperto autoproclamato di aria calda
Il nostro architetto più esperto, Andreas, si è unito a noi qualche settimana prima della chiusura e ha sempre un buon asso nella manica. Aria calda e ancora molto dietro: In questo breve periodo ha già affrontato un bel po' di cose, tra cui la fondazione della gilda della modularizzazione nel settore dei negozi online (OSA). La gilda mira a promuovere lo scambio di esperienze tra i team. È stato anche determinante per la creazione dei nuovi ruoli di "Architetto Software" all'interno dei team di sviluppo e di "Ingegnere Capo".
Lo stack tecnologico di OSA consiste principalmente in C# .NET Core nel backend e in ReactJs con GraphQL nel frontend. Andreas sta attualmente lavorando per sviluppare ulteriormente il nostro framework UI e per far funzionare il negozio in modo indipendente dal resto del monolite, al fine di semplificare il lavoro degli sviluppatori. I team sono responsabili sia del backend che del frontend del loro contesto.
Area operativa
Boško - Nel nostro business di breve durata, scalpelliamo le nostre decisioni con il burro invece che con la pietra
Boško è sia il più longevo che il più giovane Domain Architect. Ha iniziato con noi come sviluppatore software e ora è responsabile delle operazioni come architetto. Negli ultimi mesi abbiamo messo in pausa la maggior parte dei progetti pianificati a lungo termine (noi li chiamiamo iniziative) per adattare rapidamente i processi al massiccio aumento del volume degli ordini causato dalla pandemia di coronavirus. Boško è in stretto contatto con i team di sviluppo per assicurarsi che non ci siano debiti tecnici eccessivi. Partecipa regolarmente a riunioni; da anni prende parte ai SoCraTes Days. Ha anche promosso l'idea dell'open source nella nostra azienda e ha pubblicato il nostro ProjectsRuler su Github. Per assicurarci di essere ben posizionati dal punto di vista organizzativo per la crescita prevista, stiamo dividendo la divisione Operations in due aree. Stiamo cercando un Domain Architect per una delle due aree.
Categoria Gestione e Finanza
divisione
Marchio - Ieri eravamo sull'orlo del baratro. Oggi siamo un passo avanti.
L'agenda di Marco è sempre molto piena: Il dialogo verbale con i team e il supporto diretto ai loro architetti di soluzioni sono molto importanti per lui. Uno dei punti principali del suo lavoro è la modellazione dei processi aziendali di Category Management e Finance. Questi sono ancora in gran parte implementati nel monolite e devono essere distribuiti in contesti che comunicano tra loro in modo sincrono o asincrono per mappare i processi. Prima della pandemia, il Team Q si riuniva regolarmente per sessioni di lavagne bianche per elaborare l'interazione dei contesti in questi processi aziendali. Da remoto è un po' più complicato, ma ci stiamo lavorando. Un argomento su cui ci stiamo attualmente concentrando in questo contesto è Saghe.
Divisione piattaforme e SysOps
Olivier - apprendista di Kafka e lobbista di RavenDb
Olivier è con noi da due anni e mezzo. Nei primi tre mesi ha consolidato le idee esistenti e ha formulato la visione dell'architettura del nostro sistema distribuito. In seguito si è occupato dello sviluppo del DataTransformer. Una libreria che consente di inviare le modifiche ai dati dal server SQL all'Azure Service Bus con un ritardo di pochi millisecondi. Ha anche scritto il Domain Modeler, in cui manteniamo la nostra mappa di contesto. Olivier è un Domain Architect nell'area Platform and SysOps. Quest'area è composta da team di piattaforma che facilitano ai team di sviluppo delle altre aree il lavoro autonomo con la piattaforma cloud. In questo modo ci adattiamo a un'organizzazione DevOps flessibile. Ad esempio, il Team BlackJack gestisce i nostri cluster SQL server e MongoDb. Il Team Bender! è responsabile del cluster Kubernetes e offre strumenti come il "modulo di riferimento" come modello per un microservizio .NET Core standard con connessione ad AppInsights, Azure Service Bus, DB, ecc. Grazie a questo modello, possiamo distribuire un nuovo microservizio in modo molto semplice. Anche l'automazione delle pipeline CI/CD di Azure DevOPs supporta questo processo. Inoltre, grazie ai pacchetti condivisi, rafforziamo il bootstrapping e le funzionalità di base dei nostri microservizi.
La maggior parte dei servizi è strutturata secondo un design basato sulla Clean Architecture. In linea di principio, tuttavia, i team di funzionalità possono definire autonomamente il design dei loro servizi. Ecco una rappresentazione schematica:
Al momento Olivier è molto impegnato con Kafka. Vogliamo migrare gran parte della nostra pipeline di dati su Kafka per poter gestire meglio i backfill, tra le altre cose. È anche un fan di RavenDb ed è sempre alla ricerca di modi per utilizzarlo. Fin qui tutto bene: sul Tech Radar, che viene aggiornato regolarmente dal Team Q, puoi vedere con quali tecnologie stiamo lavorando.
Diventa parte del Team Q
Sei entusiasta di queste sfide e vuoi plasmare il futuro dell'e-commerce con noi? Qui puoi trovare le nostre posizioni aperte.
Nicolas Lefebvre
Lead Software Architect
Nicolas.Lefebvre@digitecgalaxus.chCome primo sviluppatore a tempo pieno alla Digitec Galaxus per un po' di tempo, sono stato, tra le altre cose, team leader di Goldfinger e Bender! e capo dell'Architectural Guild (l'A-Team).
Nel frattempo, insieme ai nostri Architetti del Dominio, sono solo il guardiano della torre d'avorio. Sviluppiamo costantemente l'architettura target, lavoriamo a stretto contatto con i team di sviluppo anche durante l'implementazione e formiamo il comitato di revisione dell'architettura.
A causa delle mie richieste di pull piratesche, rotture di build inimmaginabili e deploy di squali il venerdì pomeriggio, mi chiamano anche 🅷🅰🅲🅺🅴🆁🅰🅽.
6 commenti
later