Come si formula correttamente il modello di dominio nella progettazione guidata dal dominio (contesti limitati, domini)?

Question

Come si formula correttamente il modello di dominio nella progettazione guidata dal dominio (contesti limitati, domini)?

#1 da (3 voti)

0

Supponiamo che tu abbia alcune applicazioni che si occupano di alcuni domini core diversi.

Gli esempi sono truccati ed è difficile mettere un esempio reale con dati significativi insieme (in modo conciso).

In Domain Driven Design (DDD) quando si inizia a guardare Contesti e domini / sottodomini limitati, si dice che un Contesto Limitato è una "fase" in un ciclo di vita.

Un esempio di contesto qui sarebbe all'interno di un sistema di e-commerce. Sebbene sia possibile modellarlo come un singolo sistema, giustificherebbe anche la suddivisione in contesti separati. Ognuna di queste aree all'interno dell'applicazione ha il proprio linguaggio onnipresente, il proprio modello e un modo per parlare con altri contesti limitati per ottenere le informazioni di cui hanno bisogno.

I domini Core, Sub e Generico sono l'area di competenza e possono essere numerosi in applicazioni complesse.

Dire che esiste un lungo processo che riguarda un'entità, ad esempio un libro in un dominio principale. Ora guardando i contesti limitati ci possono essere una serie di fasi nel ciclo di vita dei libri. Dì schemi, creazione, correzione, pubblicazione, fasi di vendita.
Ora immagina un secondo dominio di base, forse un dominio del negozio. L'editore ha una propria filiale di negozi per vendere libri. Il negozio può avere un numero di contesti limitati (fasi del ciclo di vita), ad esempio un contesto "Stock" o "Inventario".

Nel primo dominio c'è probabilmente una tabella di database del libro con fondamentalmente solo un ID per tenere traccia delle diverse Entità del libro nei diversi cicli di vita.

Ora supponiamo che tu abbia più di 10 domini di supporto, ad es. Utenti, cataloghi, inventario ... (difficile pensare a esempi rilevanti).

Ad esempio un DomainModel per la fase Outline del libro, la fase di creazione, la fase di correzione, la fase di pubblicazione, la fase di vendita. Quindi, per il dominio principale del negozio, probabilmente ha un numero di fasi del ciclo di vita.

public class BookId : Entity
{
    public long Id { get; set; }
}

Nella fase di creazione (Contesto Limitato) il libro potrebbe essere una semplice classe.

public class Book : BookId
{
    public string Title { get; set; }
    public List<string> Chapters { get; set; }
    //...
}

Mentre nella fase di pubblicazione (Contesto limitato) avrebbe tutto il testo, la data di rilascio ecc.

public class Book : BookId
{
    public DateTime ReleaseDate { get; set; }
    //...
}

Il vantaggio immediato che posso vedere separando dalla "fase del ciclo di vita" è che è un ottimo modo per separare la logica di business, quindi non ci sono Entità o Servizi di dominio onnicomprensivi. Un problema che ho è capire come definire concretamente le regole per il layout fisico del modello di dominio.

A. Il modello di dominio viene "modellato" in modo tale che ci siano tanti contesti limitati (progetti separati, ecc.) In quanto vi sono fasi del ciclo di vita attraverso i domini core in un'applicazione complessa?

Modifica: rispondi ad A. Sì, secondo la risposta di Alexey Zimarev dovrebbe esserci un intero "Dominio" per ogni contesto limitato.

B. Il modello di dominio è generalmente organizzato in contesti limitati (o domini o entrambi)?

Modifica: Rispondi a B. Ogni Contesto Limitato dovrebbe avere il suo "Dominio" completo (Servizio / Entità / VO / Archivi)

C. Significa che possono esserci facilmente 10 "Domain" di modelli "segregati" e più progetti possono usarli (Entities / Value Objects)?

Modifica: risposta a C esiste un "dominio" completo per ogni contesto limitato e il modello di dominio (livello / progetto Voce / VO) non viene "utilizzato" dagli altri contesti limitati direttamente, solo tramite percorsi scelti (es. tramite Eventi di dominio).

La parte che sto cercando di capire è come il modello di dominio viene effettivamente implementato una volta che inizi a capire i tuoi contesti limitati e domini core / secondari, in particolare in applicazioni complesse. L'obiettivo è stabilire le definizioni che possono aiutare a separare le Entità tra Contesti e Domini Limitati.

domain-driven-design domain-model

posta lko 11.10.2013 - 18:33

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design domain-model

Prestazioni di operazioni a 8 bit su architettura a 64 bit Intervista per lavoro che usa abilità con cui non hai esperienza? [chiuso]

score 3 · Accepted Answer

Per essere onesti, la tua domanda non è facile da capire.

Quando avvii il tuo viaggio DDD, identifica i tuoi domini e i contesti limitati. Idealmente hai un contesto limitato per dominio ma dipende. Ogni dominio ha il proprio modello di dominio, lo menzioni tu stesso. Ma questi modelli di dominio non hanno nulla in comune. Non si conoscono l'un l'altro. La tua idea di avere una classe base per due entità di domini diversi non si adatta a DDD. I modelli di dominio reale non consentono l'accesso a qualsiasi cosa all'interno del modello di dominio a qualsiasi cosa al di fuori del contesto limitato. Tutte le comunicazioni tra contesti limitati passano attraverso interfacce predefinite come query e comandi se si esegue CQRS. In questo modo puoi rendere i tuoi componenti liberamente accoppiati e consentire a gruppi diversi di lavorare su domini diversi senza dipendere l'uno dall'altro.

Contesto limitato indica sempre un'applicazione separata. Puoi pensare ad una soluzione separata però. Comprenderà un progetto di dominio con entità, VO, comandi. Comprenderà anche progetti di servizi con gestori di comandi e gestori di query. Comprenderà progetti di trasporto come un'applicazione che utilizza il bus di servizio per comandi ed eventi.

Ricorda che l'utilizzo degli eventi di dominio è fondamentale per consentire l'inversione del controllo a livello di logica aziendale, quando un dominio informa tutti gli altri sulle cose che accadono, consentendo a, di reagire di conseguenza e svolgere le attività necessarie. Puoi pensare all'evento di pagamento degli ordini nel dominio delle vendite che innesca un processo di dispacciamento nel dominio dell'inventario. Il dominio delle vendite non ha nemmeno bisogno di sapere del dominio di inventario.