Posizione dei componenti della soluzione: centralizzazione rispetto a più istanze rispetto a librerie

Question

Attualmente siamo nelle prime fasi della costruzione di un sistema sostanziale, con l'obiettivo di fare gran parte di ciò che fanno diversi sistemi esistenti, in modo flessibile, estensibile, mantenebile. Supererà più istanze complete per diversi clienti. Una delle cose che continuano a passare in tutto il sistema è: Dove dovrebbe sedersi [componente x]?

Potremmo:

• (UN) Centralizzarlo completamente in un unico servizio Web separato, condiviso da ogni istanza; La configurazione verrebbe tenuta centralmente in modo che possa dare a ciascuna istanza ciò di cui aveva bisogno e può includere plugin specifici per istanza
• (B) Assero come un servizio separato, ma installalo più volte, configurato singolarmente per ogni istanza principale della soluzione; Il servizio potrebbe essere utilizzato da diversi componenti di cooperazione in un'istanza
• (C) Crea la funzionalità come libreria e incorporarla direttamente negli altri componenti

Per ognuno ci sono alcuni pro e contro chiari:

UN è efficiente in termini di risorse e consente facilmente il monitoraggio dell'EG di attività in tutta la soluzione. Fare un singolo servizio sufficientemente configurabile/flessibile creerà ulteriori sfide di sviluppo. Gli aggiornamenti al codice potrebbero avere un impatto su tutta la soluzione sia in termini di pianificazione dei tempi di inattività che di test/distribuzione, 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 modo più gestibile, ma sarà necessario un maggiore sforzo per eseguire il lancio in più di un posto.

C Rimuove la necessità di un servizio separato e offre il potenziale per la massima flessibilità se il codice di chiamata non deve essere limitato a svolgere tutte le funzioni tramite l'API di servizio Web; Gli aggiornamenti al codice richiederebbero la riduzione delle DLL ovunque venivano utilizzate, che potrebbero essere in ogni componente di un'istanza piuttosto che solo una volta per istanza come in B.

Ci sto pensando specificamente da una funzionalità POV non, preoccupandomi per ad esempio in cui i dati sono effettivamente archiviati. Ho ignorato l'opzione D, "Copia e incolla il codice dappertutto o il reimplement Willy Nilly".

Mi chiedo come si applica a una gamma di componenti, da specifiche funzioni aziendali, a cose più ampie come la registrazione, la gestione degli errori, l'accesso ai dati, ecc. Ecc. Mi rendo conto che la risposta finale dipenderà sempre fortemente da ogni esempio, Ma ci sono considerazioni che non ho menzionato che potrebbero avere un grande impatto? Ci sono esempi in cui è un gioco da ragazzi assoluto? Esiste un modo sistematico per aiutare a prendere questa decisione? Ho perso completamente un'intera opzione?

EDIT (un po 'più dettagliatamente nel caso in cui faccia la differenza): storicamente, a causa della mancanza di previdenza, abbiamo soddisfatto le esigenze di diversi clienti simili ma anche sostanzialmente diversi facendo sostanzialmente l'intera base di codice a parte una manciata di banali biblioteche. Siamo decisamente impegnati in una sorta di approccio SOA con la riscrittura, e certamente una base di codice drammaticamente più condivisa, ma potrebbero esserci ancora qualche vantaggio o requisito per mantenere una certa separazione per ogni "istanza", con la quale intendo un'intera raccolta di servizi Fornire tutto ciò che è necessario per un cliente: il cliente può richiedere la propria installazione logicamente o addirittura separata; L'istanza di un cliente può consistere in 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 lasciare che funzionino tutti Insieme in diversi modi per diversi clienti, o in alternativa avere uno dei moduli necessari all'interno di un cliente, ma la natura vagamente accoppiata dei servizi consentirebbe comunque di aggiungere un altro modulo a un cliente esistente o spostare una risorsa -Il modulo intensivo al proprio hardware per un solo cliente.

Non fraintendetemi, apprezzo tutti i punti realizzati, ma penso che non sono proprio in un luogo mentale in cui semplicemente il fatto che fare qualcosa in un certo modo, il che potrebbe sicuramente offrire qualche beneficio in alcune situazioni, Potevo portare anche a problemi se gestiti male, è del tutto inaccettabile. Quindi è meglio solo non lasciare che la possibilità esista anche se ciò porta a una maggiore complessità/sforzo/ecc. Un po 'come non permettere alcol in casa, perché sai che se è lì potresti berlo tutto da solo e correre in strada nelle mutande, anche se una bevanda tranquilla per rilassarsi dopo il lavoro potrebbe essere bello. Probabilmente dovrei smettere di waffling ora ...