A quale domanda viene data risposta da DDD? [duplicare]

Il Domain Driven Design è fondamentalmente un rimedio alla nostra tendenza a soffiare gli oggetti e le preoccupazioni tecniche e "filosofiche" l'una nell'altra. Anche nei casi in cui abbiamo la netta sensazione che queste due cose siano meglio affrontate come preoccupazioni separate, può essere difficile riuscire a creare coerentemente le divisioni giuste senza una chiara regola.

E così, la regola di base è "creare e mantenere una parte distintamente riconoscibile della tua applicazione (il dominio) in cui contenga i tuoi oggetti e metodi puri riconoscibili dal business, i nomi di cui ogni uomo d'affari dovrebbe riconoscere. "

Si tratta di evitare le situazioni in cui sia le regole aziendali che della tecnologia sono difficili da cambiare perché non sono ben isolate l'una dall'altra.

_{Nella mia esperienza con le applicazioni web, ho scoperto che quando i principi DDD e DDD non sono esplicitamente rispettati, c'è una tendenza strong a incanalare le regole aziendali direttamente in Codice UI. Quindi, si finisce con più copie delle regole di business (una per ogni pagina), e né quelle di né di quell'utente possono essere facilmente modificate.}

Penso che il DDD abbia a che fare con un concetto un po 'sottotono, che io chiamo "Separazione Problema / Soluzione". Risolve il problema di Riutilizzo dei problemi anziché solo il riutilizzo delle soluzioni.

Per come la vedo io, dovresti modellare gli elementi problematici in un modo che non dipende da come sarebbe risolto. Questa sarebbe la parte "analisi" di OOAD, in cui definisci concettualmente quali sono gli elementi del problema. Nel frattempo, mentre sviluppi ulteriormente la tua soluzione - ovvero progettando una delle possibili soluzioni - aggiungi elementi che riguardano specificamente la quella soluzione . Questa sarebbe la parte "design" dell'applicazione, in cui definisci come devono essere manipolati quegli elementi del problema o come dovrebbero interagire in modo che il problema sia risolto.

Come esempio concreto, sviluppo software medico (acquisizione, elaborazione e visualizzazione di dati biosegnali, soprattutto). La nostra azienda ha una manciata di prodotti software, ognuno dei quali risolve problemi simili in modi leggermente diversi, a seconda delle specialità mediche. Dopo analisi, cioè analisi del problema , abbiamo visto ripetutamente gli stessi concetti ricorrenti. Questi concetti sono stati progettati in oggetti (o interfacce o classi astratte) e inseriti in un assembly chiamato Company.BioSignals.DomainModel . Ora abbiamo una mappatura uno-a-molti tra una parte circoscritta e relativa al problema della base di codice e un insieme di parti relative alla soluzione della base di codice.