Estensibili con DDD: Modulo Vs Contesto Limitato in DDD con MEF

Question

Eric nel suo libro tocca l'argomento Moduli molto poco. Inoltre, non parla della relazione della struttura dei moduli con contesti limitati con esempi. I contesti limitati contengono moduli o moduli che contengono contesti limitati? Quando un'applicazione ha DDD, quanto può essere estensibile?

La struttura dell'applicazione è molto importante quando progettiamo applicazioni estensibili. Il framework Microsoft MEF può auto-scoprire moduli/componenti da una DLL.

Facciamo un esempio. In un'applicazione di e-commerce, possiamo avere un contesto limitato per l'elaborazione dei pagamenti . L'elaborazione dei pagamenti può essere astratta, quindi posso estendere l'app con altri processori di pagamento come Paypal o Payflow. Attualmente ho solo Paypal, e pochi mesi dopo voglio integrare Payflow. Per integrare Payflow, posso avere un assembly (una dll) che implementa l'interfaccia dell'elaborazione dei pagamenti . Posso rilasciare quella DLL nell'applicazione e il MEF la scoprirà automaticamente.

La sfida qui è, la dll creata per l'elaborazione del pagamento PayFlow è un modulo, non un Contesto Limitato (BC). Se l'ho creato come BC, abbiamo due BC per l'elaborazione dei pagamenti . (Il BC creato per Paypal e il BC per il Payflow). Se strutturiamo l'applicazione con i moduli all'interno di un Contesto Limitato e il Contesto Limitato come un assembly (dll), i moduli possono risiedere nel BC come cartelle e non assemblati (si può pensare ad esso come una libreria C# creata in Visual Studio).

Come possiamo gestire questo problema di estensibilità con DDD? È Elaborazione pagamento, un BC e diverse cartelle sotto di esso come moduli, uno per Paypal ecc ... O abbiamo bisogno di sub-BC all'interno di un altro BC?

Answer 1

Eric nel suo libro tocca molto poco il tema dei moduli. Inoltre, non parla della relazione tra la struttura dei moduli e i contesti limitati con esempi.

Sì, sono d'accordo sul fatto che il modulo e la struttura BC non ottengano una copertura sufficiente nel libro. Raccomando Implementing Domain-Driven Design by Vaughn Vernon per ulteriori informazioni.

I contesti delimitati contengono moduli o moduli contenenti contesti delimitati ?

BC contengono moduli. Un modulo è simile a un BC più leggero e appartiene anche al linguaggio onnipresente.

Quando un'applicazione ha DDD, quanto può essere estensibile?

Dipende da come lo si disegna. Nulla di DDD stesso impedirebbe l'estensibilità.

sta elaborando pagamento, un aC e cartelle diverse sotto di esso come moduli, uno per Paypal, ecc ... o abbiamo bisogno sub-BC all'interno di un altro aC?

Vorrei modellare ogni integrazione del processore di pagamento come un modulo all'interno di un singolo processo di pagamento BC. Inoltre, ogni integrazione è una ACL tra il modello di elaborazione dei pagamenti e una terza parte come PayPal.

Oppure abbiamo bisogno di sub-BC all'interno di un altro BC?

No, ma questo tocca una nozione interessante di un sub-BC. Non penso che un sotto-BC sia una buona idea perché credo che le organizzazioni gerarchiche possano essere pericolose portando a progetti rigidi (si consideri, ad esempio, l'OOP con gerarchie di tipo esplicite) può essere problematico. Invece, optare per un modello più piatto con potenzialmente più BC. Inoltre, nel tuo caso, la struttura desiderata può essere raggiunta con i moduli.