2013-09-04 16 views
36

Ho letto il libro di Eric Evan e sto leggendo il libro di Vaughn Vernon ora. Sono nel secondo capitolo in cui parla dei sottodomini e del contesto limitato e sono completamente confuso ora.Confuso su contesti e sottodomini limitati

Da quello che ero in grado di distillare, dovrebbe esserci una relazione 1: 1 tra un BC e un SD. Tuttavia, ho letto in altri posti che questo non è necessariamente il caso.

Qualcuno può spiegarmi la relazione tra un BC e un SD?

+0

Forse spiegare la differenza tra un BC e SD aiuterà – Chris

risposta

4

Rileggendo il contesto di prenotazione dal libro blu 18 volte mi ha aiutato finalmente a ottenere una maniglia. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/

Questo articolo ha aiutato così: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/

+5

bello, ma se si copia qui dagli articoli che cosa rispondere alla domanda, sarà fantastico! –

+5

ed ecco una sintesi dal secondo articolo: Un sottodominio delimita un dominio ed esiste all'interno dello spazio del problema. Un contesto limitato delimita il modello di dominio ed esiste all'interno dello spazio della soluzione. L'ideale è l'allineamento completo tra un sottodominio e un contesto limitato, tuttavia nella pratica un certo grado di flessibilità deve essere accettato a questo riguardo. –

+1

Non sono d'accordo con il collegamento gorodinksi poiché parla troppo in senso tecnico e non abbastanza in senso commerciale. @JefClaes risposta è molto meglio. –

35

Un sottodominio è una parte del vostro business. Esistono domini principali, domini di supporto e domini generici. I domini principali sono dove sono i soldi, i domini di supporto supportano il tuo core business, e domini generici sono quelli di cui hai bisogno, ma non ti interessa molto, quindi probabilmente li acquisteresti sullo scaffale. Per una compagnia di assicurazioni, il dominio principale è l'assicurazione, un dominio di supporto potrebbe essere un portafoglio clienti e un dominio generico potrebbe essere qualcosa come i timesheet.

In generale, un contesto limitato è un limite entro il quale la lingua ubiquitaria è coerente. Nel walalla DDD ogni sottodominio vivrebbe nel suo contesto limitato. In realtà, tuttavia, c'è un'eredità, ci sono pacchetti che cercano di fare tutto in una volta ... il che costringerà tutti i tipi di relazioni di awkard.

+1

bella spiegazione, grazie! –

13

Cerco di spiegare questi concetti con la mia comprensione.

In DDD, tutto dovrebbe essere comunicati in lingua onnipresente in modo che la squadra e di business team tecnico può utilizzare gli stessi termini e hanno stesse opinioni sui problemi

  • dominio in DDD rappresentare vero problema nel mondo degli affari. Ad esempio: Il commercio elettronico è un dominio, il sistema Payroll è un dominio
  • Il dominio è diviso in molti domini , quindi ogni sottodominio si concentra su problemi minori. Ad esempio: Il commercio elettronico ha molti sottodomini come: Carrello acquisti, Fatturazione, Catalogo prodotti, Informazioni cliente ...
  • Ogni sottodominio dovrebbe avere responsabilità esplicite quindi ha un limite per limitare le loro funzionalità, il limite aiuterà focus di dominio per fare solo 1 cosa e fare bene. Questo limite è considerato come contesto limitato del dominio secondario. Il contesto limitato definirà:
    • Quanti modelli di dominio necessari per il sottodominio?
    • Quali proprietà sono necessarie in ogni modello?
    • Quali funzionalità sono necessarie nel sottodominio?

Es: Carrello sottodominio bisogno modelli: Carrello, prodotto, clienti Info ... e contiene le funzioni per eseguire CRUD sul carrello. Note: il modello Prodotto e Cliente nel sottodominio Carrello acquisti potrebbe non essere lo stesso con i modelli nel sottodominio Cataloghi prodotto e Profili clienti, ma solo contenere le proprietà necessarie da visualizzare nel Carrello acquisti.