architettura adatto per riscrittura con integrazione + migrazione scenario

Question

Recentemente abbiamo iniziato un progetto al lavoro azienda per cui al di ristrutturare e riscrivere il nostro paesaggio sistemi e salvare il futuro dei nostri figli.

Abbiamo 3-4 sistemi legacy che assolutamente non possono essere adattati a nuovi casi d'uso a causa del codice di orribile, ma ancora gestire piuttosto una grande quantità di ordini al giorno tramite interfacce e formati diversi, come e-mail, XMLRPC, interfaccia web.

Così abbiamo pensato di scrivere un nuovo sistema da zero sulla base di un modello di dominio completamente riprogettato. A causa della non possiamo semplicemente cambiamo i vecchi sistemi off e siamo davvero una piccola squadra, siamo giunti alla conclusione che abbiamo bisogno di un'architettura e un approccio che ci permette il graduale sviluppo del nuovo sistema e mettere le parti di esso vivono e facilmente (leggi; veloce) integrare nuove interfacce, i partner e con le applicazioni legacy e interfacce.

L'idea era quella di ridisegnare completamente l'intero modello di dominio da zero, creare un ordine di servizio e di utilizzare Apache Camel con un contenitore OSGi per imitare le vecchie interfacce di routing gli ordini per l'eredità e dai nuovi sistemi e disaccoppiare il trattamento format e si trasportare dal nuovo sistema. A causa dello sviluppo graduale vorremmo scegliere sono più architettura "service centric" che ci consentirà graduale miglioramento, riutilizzabilità e scalabilità. Sembra tutto bello sulla carta, e ho letto un bel po 'di "SOA", ma fino a quando aspettato l'hype a morire e le "parti buone" a rimanere, ma la maggior parte del discorso è ancora su un astratto e impreciso "tecnico vendite" di livello sembra.

I trovare l'approccio "Shared Data Service / base" piuttosto problematico se ho entità con un sacco di relazioni, come ordine, con un grande grafico abbastanza. Se vorrei creare un servizio individuale per le operazioni CRUD sui Ordini e le altre società di basare quelle più astratte su, sarebbe davvero problematico o impossibile da gestire ACID, l'integrità relazionale o si dovrebbe sacrificare l'autonomia di tali servizi e di interconnessione loro, il che renderebbe i servizi del tutto inutile (e forse piuttosto lento). O ho capito qualcosa di sbagliato?

Quindi la mia idea era quella di creare semplicemente un DAL "tradizionale" con bel JPA POJO, ovviamente con le interfacce, e distribuirlo come un semplice, con versione fascio OSGi per i servizi di business e di processo per l'uso, avere una mappatura più astratta. Tali servizi sarebbero poi semplicemente utilizzare ed esporre la loro interfaccia con il bus. Per servire il raro caso di necessità di accesso ai dati individuali, come per l'arricchimento dei contenuti in cammello o di dati alla rinfusa importazione o di reporting, un brutto "tutte le entità di servizio inclusi" potrebbe essere creato che risolverebbe l'acido e l'integrità problema.

Fin qui tutto bene, ma: come dovrebbe WebUI (che non è per lo più CRUD come ho già detto, e quindi in realtà un processo astratto) l'accesso ai dati? Direttamente utilizzando l'APP POJOs renderebbe accoppiato piuttosto tighly, ma creando una mappatura e introdurre un altro modello quasi identico e utilizzare il suddetto "servizio mostro DAL" suono doesnt troppo buono.

Cosa ne pensi? Dove si trova un buon equilibrio tra senso, eleganza e praticità?

Mi dispiace che queste sono alcune domande e il testo è piuttosto lungo, ma ho sentito che era importante per descrivere la situazione che stiamo affrontando qui in un po 'più in dettaglio.

Grazie per il vostro tempo:)

Answer 1

Non si tratta tanto di una risposta come una nota che augura buona fortuna.

Abbiamo una situazione che è lo stesso / diverso vostra forma, e sta dimostrando di essere un proble molto difficile da affrontare in modo efficace.

Credo che il tuo approccio è OK, sembra che tu stia colpendo un equilibrio OK.

Si può prendere aziendali modelli di integrazione, come quelli pubblicato da Martin Fowler , ma se questo si arriva a in cui si desidera / bisogno di essere resta da vedere.

Altre opzioni: c'è la macchina "salsiccia": dove si spinge il vecchio sistema in un sistema che genera il codice "nuovo" (in Java o .Net), che diventa la tua nuova piattaforma. la cosa buona è che ora avete una base di codice in una lingua che può lavorare con, la cattiva notizia è che sarà il più grande pila più terribile di spaghetti mai immaginato.

Anche allora si tratta di un impegno enorme. Un ente governativo qui speso 2 o 3 anni e $ 5 milioni di ottenere questo fatto. Non era bella o indolore, ma sembra aver funzionato. Se chiedete in giro abbastanza (cioè: non su StackOverflow). Si dovrebbe trovare persone che hanno affrontato la migrazione al largo delle piattaforme tua bloccato con, entrare in una conversazione con loro