Penso che questo sia un ottimo esempio di quando i contenitori IoC possono essere utili. Puoi creare diverse configurazioni per ciascun cliente che decide come inizializzare le tue fabbriche, quali strategie vengono iniettate, quali classi usi per quali interfacce e così via.

Questo, insieme a un design pluginish completo, ti consente di variare la funzionalità in modo sottile in un modo davvero accurato. La vera sfida è, naturalmente, trovare quali parti si stanno muovendo e dove è necessario proteggersi dal cambiamento.

La domanda non è indipendente dal progetto concreto e quali sono le capacità tecniche necessarie per garantire la modularità.

In termini di pattern, questo è un classico Pattern di strategia insieme a Inversion of Control . Devi astrarre ogni funzionalità concreta e darne una spiegazione al modulo.

Supponiamo che stavi facendo un software per calcolare le tasse. In un'implementazione ingenua implementeresti un'interfaccia utente con pulsanti e azioni e accanto al calcolo delle imposte. Il tuo software è un vero successo, hai richieste da tutto il mondo di personalizzare per molte lingue e sistemi fiscali.

L'internazionalizzazione si fa facilmente con la sostituzione delle stringhe (per così dire). Ma, oltre agli altri linguaggi, devi gestire completamente le leggi di business / leggi fiscali . Per portare a termine il tuo compito, inizi ad astrarre la logica commerciale concreta in moduli. Per esempio. definisci un'API comune per ogni set di regole aziendali e incapsula le regole in diversi motori .

Separa i comandi come calculate taxes dall'implementazione nel motore concreto. Così alla fine la tua applicazione agisce come un lettore di dischi con l'abilità astratta di riprodurre musica e quale musica viene riprodotta dipende dal vinile concreto.

Nell'interfaccia utente sono presenti contenitori che possono essere riempiti dinamicamente con componenti in base alla configurazione del modulo in uso.

Il modo in cui risolvi questo problema tecnicamente dipende da te:

• utilizzando un sistema di plugin
• compilazione di un prodotto da diverse fonti
• spedizione del prodotto con ogni modulo possibile e decidi in fase di esecuzione, cosa usare
• con un'applicazione web con endpoint leggermente diversi per i componenti del cliente

ecc. pp.

tl; dr

devi rendere la tua pluggable

Penso che il nocciolo del tuo problema sia una scomposizione insufficiente dei tuoi "moduli". Devi dividerli in un modello a grana fine abbastanza grande da poter essere riutilizzato di più. Se il Cliente A, che chiamerò Cust1, vuole qualcosa nel Modulo B, che chiamerò Mod1 che è diverso dal Cliente C, che chiamerò Cust2 vuole, allora probabilmente vorrai estrarre i bit comuni di Mod1 in un nuovo Modulo Mod2 , che è condiviso tra Cust1 e Cust2. Quindi Cust1 può creare un nuovo modulo basato su Mod2 che chiameremo Mod2Cust1 e Cust2 può creare un nuovo modulo basato su Mod2 che chiameremo Mod2Cust2. Se non c'è modo di decomporre Mod1, nei sottomoduli, allora sono intrinsecamente abbastanza diversi da non poterli riutilizzare, e hai bisogno di moduli separati per ogni cliente.