Modellazione di un progetto espandibile Domain Driven Design

Question

Modellazione di un progetto espandibile Domain Driven Design

#1 da (1 voti)
#2 da (-2 voti)

1

Supponiamo che stiamo sviluppando un'applicazione con moduli (Vendite, Contabilità, Acquisti ecc.)

Un esempio qui è:

Il modulo Vendite è il modulo base / primario disponibile e il modulo Contabilità è un modulo complementare.

SalesModule
-. Product

E

AccountingModule
-. Account
-. Journal

Se dovessimo dirlo:

If the Accounting Module were installed, then it will provide a direct integration with the Product class from the Sales Module, such as : a Product now has a List of Account which if a transaction is applied to the Product, a Journal will be posted according to the Account.

Nella mia mente, immagino che Product abbia una proprietà di List<Account> , ma sarebbe impossibile senza aggiungere quella proprietà direttamente nella classe Product , rendendo Product ora dipendente dal Modulo di Contabilità quando SalesModule dovrebbe essere in grado di eseguirlo senza.

Un'altra soluzione che ci viene in mente è quella di aggiungere SalesIntegrations classes (ProductAccount, ecc.) per integrare il Product precedentemente descritto, rendendolo indipendente. Ma questa soluzione non sembra 'naturale' come dire che a Product has a list of Accounts .

Da quanto ho capito, fare DDD significa conoscere in anticipo l'intero concetto di regole aziendali.

E se venisse richiesto un requisito per aggiungere un nuovo progetto che completasse il precedente progetto DDD, avendo solo la sua DLL (nessun accesso al codice sorgente)?

domain-driven-design design-patterns modules concepts

posta Samuel Adam 18.11.2013 - 11:55

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design design-patterns modules concepts

Crea una categoria Objective-C per indirizzare i metodi in base a un tipo specificato Il qo dell'applicazione riguarda la priorità e la larghezza di banda

score 1 · Answer 1

Nel libro di Eric Evans, il problema che stai vivendo è un po 'toccato quando si ha a che fare con contesti limitati, che sono contesti nati separati (legacy, team diversi, ecc.) e devono interagire.

Dipende tutto dall'investimento e dalle risorse, ma se come hai detto tu hai solo accesso alle DLL, non puoi usare alcun approccio che implichi il refactoring dei punti comuni dell'altro modulo, quindi dovrai conviverci in un moda simile a trattare con codice legacy.

Gli approcci che hai sono descritti nelle strategie di mappatura del contesto. A mio parere, data l'incapacità di lavorare sul codice esistente, potrebbe essere un approccio difensivo come uno "strato anti-corruzione".

score -2 · Answer 2

Molti framework MVC fanno uso di Inversion of Control per iniettare dipendenze e renderle più flessibili. Non sei sicuro di quanto dovrebbe essere stretta la tua integrazione, e anche in che modo disaccoppiare questi moduli dovrebbero funzionare. per esempio. sono tutte applicazioni indipendenti?

Potresti voler dare un'occhiata ad alcuni pattern che iniettano dipendenze, è un modo di avere moduli liberamente accoppiati. È inoltre possibile creare interfacce per formalizzare e creare "contratti" tra i moduli. per esempio. AccountAwareInterface , con qualcosa come setListAccount e getListAccount .

Se il modulo Product dovesse funzionare indipendentemente dagli altri moduli, estenderei le classi di prodotti interessate e integrerei lì. Ma come usi l'una o l'altra classe, certamente deve essere configurata correttamente.

Non sono sicuro che aiuti un po '.