Modellazione del dominio, oggetti del dominio in DDD

Question

Sono davvero nuovo per DDD e cerco di cogliere alcuni dei concetti.

Qualcuno potrebbe spiegarmi l'idea alla base della modellazione del dominio in DDD.

Ho già esaminato la spiegazione di wikipedia: http://en.wikipedia.org/wiki/Domain_model ma sembra che ci siano alcune aree grigie nella mia comprensione.

In base a quello che ho capito, la modellazione di dominio comporta la costruzione di un modello intorno alle entità di business per esprimere le loro relazioni, esprimere i soggetti che partecipano al modello ecc ..

Non è questo qualcosa che è stato in pratica sempre? nel mondo orientato agli oggetti, si modellano le entità aziendali in classi, oggetti ecc. e si costruisce il software attorno a questo.

Quello che non capisco è l'enfasi del Domain Modeling in DDD. È lo stesso modello di oggetto/classe che trovi nel mondo OO o è qualcosa di nuovo in DDD? Come si differenzia dalla progettazione/modellazione Object Oriented?

Le vostre risposte sono molto apprezzate.

Answer 1

Una distinzione è che un'implementazione "corretta" dello Domain Model Pattern in DDD è isolata dai problemi trasversali.

Ad esempio, non contiene nulla a che fare con database o altra persistenza. Dove contiene la logica di convalida, è la convalida aziendale, non "il nome supera la lunghezza della colonna?" convalida.

L'idea è che il modello di dominio incapsuli "l'azienda" - in termini commerciali ("linguaggio ubiquitario"), per quanto possibile - e esponga aspetti rilevanti dell'azienda al "programma" senza acconsentire al esigenze del software.

Il rovescio della medaglia, "il software" riguarda IO, l'interfaccia utente e simili, ma delega tutta la logica aziendale al modello di dominio.

In linea di principio, è possibile avvolgere il modello di dominio in un assieme e utilizzarlo su più applicazioni. Quando le regole aziendali cambiano, come fanno, hai un posto molto logico in cui influire sulle modifiche (perché il modello è una rappresentazione 1: 1 o quasi degli aspetti rilevanti del business ed è descritto negli stessi termini di il business).

Answer 2

Il dominio in DDD non deve essere implementato in OO. Nella mia esperienza, un modello di dominio OO è solitamente il migliore, ma ci sono esempi molto validi di situazioni in cui potrebbe non esserlo.

Si potrebbe implementare un dominio nelle regole, con un motore di regole (esempio in Paesi Bassi dove ciò viene fatto per una grande richiesta di mutuo). O potresti farlo in un linguaggio funzionale. L'essenza è che il tuo dominio, per quanto di moda sia implementato, è isolato da quelli che di solito chiamano aspetti tecnici della tua applicazione (o, come la risposta precedente lo chiama, preoccupazioni trasversali, anche se penso che ci possa essere molto bene preoccupazioni trasversali all'interno di un dominio). Uno strato isolante, che può essere implementato utilizzando adattatori, rende il dominio il più possibile, anche completamente, indipendentemente dai tecnicismi. Questo livello di solito si basa su modelli come Facciata e Osservatore.