Al momento siamo nelle prime fasi di costruzione di un sistema sostanziale, con l'obiettivo di fare gran parte di ciò che fanno molti sistemi esistenti, in un modo flessibile, estensibile e gestibile. Supporterà più istanze complete per diversi clienti. Una delle cose che continua a emergere nell'intero sistema è la seguente: dove dovrebbe [componente x] sedersi?
Potremmo:
- (A) centralizza completamente in un singolo servizio web separato, condiviso da tutte le istanze; la configurazione sarebbe mantenuta centralmente in modo che potesse dare ad ogni istanza quello di cui aveva bisogno, e potrebbe includere plugin specifici dell'istanza
- (B) lo hanno come servizio separato, ma installarlo più volte, configurato individualmente per ogni istanza principale della soluzione; il servizio potrebbe essere utilizzato da più componenti cooperanti all'interno di un'istanza
- (C) crea la funzionalità come libreria e incorporala direttamente negli altri componenti
Per ognuno ci sono alcuni pro e contro:
A è efficiente in termini di risorse e consente facilmente ad es. monitoraggio dell'attività su tutta la soluzione. La creazione di un singolo servizio sufficientemente configurabile / flessibile creerà ulteriori sfide di sviluppo. Gli aggiornamenti del codice potrebbero avere un impatto sull'intera soluzione sia in termini di tempi di inattività che di pianificazione di test / implementazione, indipendentemente dal fatto che la modifica del codice sia destinata a migliorare ogni istanza.
B utilizza più risorse, ma localizza la configurazione, che può essere meno complessa. Le modifiche al codice possono essere implementate in un modo più gestibile, ma sarà necessario uno sforzo maggiore per eseguire il roll-out in più di un luogo.
C elimina la necessità di un servizio separato e offre il potenziale per la massima flessibilità se il codice di chiamata non deve essere limitato all'esecuzione di tutte le funzioni tramite l'API del servizio web; gli aggiornamenti al codice richiederebbero la ridistribuzione delle DLL ovunque fossero utilizzati, il che potrebbe essere in ogni componente di un'istanza anziché solo una volta per istanza come in B.
In particolare, ci sto pensando da una funzionalità PoV, preoccupandomi ad es. dove i dati sono effettivamente memorizzati. Ho ignorato l'opzione D, "copia e incolla il codice ovunque, o reimplemento willy nilly".
Mi chiedo come si applica a un'intera gamma di componenti, da specifiche funzioni aziendali, a cose più ampie come la registrazione, la gestione degli errori, l'accesso ai dati, ecc. Mi rendo conto che la risposta finale dipenderà sempre molto ogni esempio, ma ci sono considerazioni che non ho menzionato che potrebbero avere un grande impatto? Ci sono esempi in cui è un assoluto senza cervello? C'è qualche modo sistematico per aiutare a prendere questa decisione? Ho perso completamente un'intera opzione?
EDIT (un po 'più in dettaglio nel caso in cui faccia la differenza): Storicamente, a causa di una mancanza di accortezza, abbiamo adattato le esigenze di diversi clienti simili ma anche sostanzialmente diversi, basandoci fondamentalmente sull'intera base di codice, a parte una manciata di librerie banali. Siamo decisamente impegnati in un qualche tipo di approccio SOA con la riscrittura, e certamente in un numero di codice notevolmente più condiviso, ma potrebbero ancora esserci dei benefici o requisiti per mantenere una certa separazione per ogni "istanza", con cui intendo un'intera raccolta di servizi fornire tutto il necessario per un cliente: il cliente può richiedere la propria installazione logicamente o fisicamente o addirittura geograficamente separata; l'istanza di un cliente può consistere di moduli A e B, un altro B e C e D ed E. Sento istintivamente che ci sono due modi per essere "SOA" qui: uno per avere letteralmente uno di tutto, e lasciarli funzionare tutti insieme in modi diversi per i diversi clienti, o in alternativa per avere uno dei moduli necessari all'interno di un cliente, ma la natura liberamente accoppiata dei servizi consentirebbe comunque di aggiungere facilmente un altro modulo a un cliente esistente o spostare una risorsa -intensivo modulo per il proprio hardware per un solo cliente.
Non fraintendermi, apprezzo tutti i punti, ma penso di non essere in un posto mentale dove semplicemente il fatto di fare qualcosa in un certo modo, che potrebbe sicuramente offrire qualche beneficio in alcune situazioni, potrebbe portare anche a problemi se gestiti male, è del tutto inaccettabile. Quindi è meglio non lasciare che esista la possibilità anche se ciò porta a una maggiore complessità / impegno / ecc. Un po 'come non permettere alcol in casa, perché sai che se è lì puoi bere tutto da solo e correre in strada con le mutande, anche se un drink tranquillo per rilassarsi dopo il lavoro potrebbe essere bello. Probabilmente dovrei smettere di chiacchierare ora ...