Quali sono i sottodomini, davvero?

Naviga le tue risposte
8

Nello studio del design orientato al dominio (DDD), mi sono imbattuto nel concetto di sottodominio, ma penso di non averlo ancora capito. La mia prima comprensione di questo è che un sottodominio è un sottoinsieme del dominio dell'applicazione. In altre parole, è una partizione dello spazio del problema. Ho letto che ci sono tre tipi di sottodominio:

  • sottodomini principali
  • supporto dei sottodomini
  • sottodomini generici

La mia comprensione era un po 'come questa: selezioniamo il dominio dell'applicazione, ed è piuttosto complesso. Poi lo esaminiamo e scopriamo un modo per suddividerlo in parti più semplici, alcune delle quali sarebbero sottodomini di base e alcuni dei quali sarebbero di supporto, mentre altri sarebbero generici.

Nella ricerca di ulteriori informazioni, ho trovato alcune persone che dicono qualcosa di diverso: esiste solo un sottodominio principale one , insieme ad alcuni sottodomini generici e nessun sottodominio di supporto di sorta.

Quindi le mie domande sono:

  1. Quali sono i sottodomini, veramente ? La mia prima comprensione è corretta, o è la seconda cosa che leggo?
  2. Come è utile questa idea dei sottodomini?
  3. Quali sono alcuni buoni criteri per l'identificazione dei sottodomini? Cosa dovremmo avere in mente quando decidiamo i sottodomini per utilizzare meglio questa idea?

EDIT: cercando un po 'di più, ho trovato il seguente:

Think of an e-Commerce system. Initially you can tell that it is an application of a shopping context. If you look more closely, you will see there are other contexts too, such as Inventory, Delivery, Accounts, etc.

Questo è quello che inizialmente pensavo fosse un sottodominio. Selezioniamo un dominio (il dominio dello shopping) e lo suddividiamo in sottodomini più semplici (inventario, consegna, account e così via). Ma nel testo in questione, si riferiscono a questi come contesti. Quindi la mia precedente comprensione non è sottodomini ma contesti?

Ho trovato una domanda qui su questo sito sulla differenza tra un sottodominio e un contesto limitato. La risposta afferma che i sottodomini sono una partizione dello spazio del problema, mentre i contesti sono partizioni dello spazio della soluzione. Tuttavia, separare il contesto dello shopping in inventario, consegna, account, ecc. Non è una partizione concettuale. Cioè, è nello spazio del problema piuttosto che nello spazio della soluzione?

    
posta user1620696 09.02.2015 - 23:08
fonte

1 risposta

7

Disclaimer : non sono un esperto di DDD, ma farò del mio meglio per rispondere alle tue domande.

Usiamo un rivenditore di libri online come esempio. Un venditore di libri si offre di vendere libri sul suo sito web, ma non stampa i libri da solo. Al contrario, ha una lunga lista di "Book Suppliers" che stampano e spediscono i libri nel suo magazzino, li impacchetta e li spedisce ai clienti di tutto il mondo.

Potresti immaginare i team che lavorano in quell'azienda?

  1. Il team di annunci : il team che seleziona i libri da elencare sul sito Web, a seconda dello stock dei fornitori.
  2. Il team per l'adempimento : responsabile della raccolta degli ordini dal sito web e della gestione del ciclo di vita degli ordini.
  3. Il team commerciale : questi sono i ragazzi che gestiscono l'aggiunta o la rimozione di fornitori dal sistema.
  4. Il team di marketing : responsabile delle campagne e delle offerte.
  5. Il team del magazzino : responsabile della raccolta di libri dai fornitori e della loro spedizione.

Ogni squadra userà i propri termini per descrivere quello che sta facendo. Le squadre useranno la lingua del dominio o il "Linguaggio Ubiquitous", come lo chiama Eric Evans. Normalmente, ogni squadra avrà un diverso modello mentale di cosa sia un'entità. Ad esempio: 

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item"

Un sottodominio è una parte particolare del dominio, in cui alcuni utenti usano un determinato linguaggio Ubiquitous. Quando la lingua cambia, questa è un'indicazione che stai attraversando un altro sottodominio.

Cosa succede se due squadre usano gli stessi termini? Sia l'adempimento che i gruppi di annunci chiamano "libro". Dovrai chiedere loro: "Che cos'è un libro per te? Quali sono i suoi attributi chiave? Come viene utilizzato?"

Le risposte a queste domande genereranno due modelli di dominio diversi o simili. Maggiore è la differenza tra i due modelli, maggiore è l'indicazione che si tratta di due contesti / sottodomini limitati. È vero anche il contrario. Più sono simili i due modelli, più è probabile che facciano parte dello stesso sottodominio.

Ciò potrebbe causare risultati molto interessanti nel tuo modello. Potresti scoprire che all'interno del sottodominio fulfillment, gli ordini passano attraverso stati diversi (nuovi - > richiesti - > spediti). Forse ognuno di questi stati richiede una gestione complessa e diversi attributi, quindi puoi dividere questo sottodominio in molti altri sottodomini.

Ciò fa emergere una domanda su quale dovrebbe essere la dimensione del sottodominio. La risposta è "lascia decidere al modello di dominio". Ogni volta che vedi un cambiamento nell'UL e nel modello, disegna un limite per quel sottodominio.

Ricorda che DDD riguarda esclusivamente l'azienda, le persone e le comunicazioni tra di loro. Lascia che guidi il tuo modello.

    
risposta data 11.02.2015 - 20:30
fonte

Leggi altre domande sui tag

utilizzando gli oggetti Integer nell'API Java Come decidere cosa forma il sistema in prova