Il modello di builder è applicabile nella progettazione basata su domini?

Question

Il modello di builder è applicabile nella progettazione basata su domini?

#1 da (10 voti)
#2 da (4 voti)

2

Ho fatto una domanda su StackOverflow riguardo a come 'best' usa il pattern Builder per costruire un Value Object che potrebbe essere costruito con o senza parametri opzionali.

Una risposta affermava che:

A builder is not part of the domain driven design paradigm because it cannot be expressed as part of your domain's ubiquitous language

Mentre Domain Driven Design suggerisce l'uso di Factory per la creazione di oggetti complessi, non pensavo escludesse altri pattern.

Questo suggerisce che un Builder non appartenga al livello dominio? Non pensavo che Domain Driven Design fosse interessato all'attuazione tecnica, come la scelta dei modelli.

domain-driven-design design-patterns builder-pattern

posta Unflux 06.03.2018 - 17:32

fonte

2 risposte

4

Non penso che DDD e il pattern di builder si escludano a vicenda, tuttavia il builder è solo un'utilità per aiutare a costruire il modello di dominio.

Se il tuo oggetto Dominio e il tuo Builder sono classi separate, allora:

L'oggetto dominio è parte fa parte del modello di dominio
Il builder non lo è - è solo una classe di utilità che aiuta a costruire il tuo modello di dominio

Se sono nella stessa classe, le linee sono leggermente sfocate. Per essere pedante, la porzione di builder della classe non è specifica del dominio. Le proprietà e i metodi sul modello di dominio costruito sono.

Per essere onesti, la distinzione è per lo più accademica e non vale la pena di discutere.

risposta data 06.03.2018 - 18:10

fonte

Leggi altre domande sui tag domain-driven-design design-patterns builder-pattern

37Signals Basecamp è un hype? [chiuso] Quali aspetti rendono i siti Web caricati più velocemente? [chiuso]

score 10 · Accepted Answer

Dopo aver esaminato la tua altra domanda non credo che tu stia parlando della banda di quattro modello di builder . Penso che tu stia parlando del schema di costruzione di Josh Bloch .

Questo ti permette di scrivere un codice come questo:

NutritionFacts cocaCola = new NutritionFacts
    .Builder(240, 8)
    .calories(100)
    .sodium(35)
    .carbohydrate(27)
    .build()
;

Il punto qui è di simulare parametri con nome in lingue che non li hanno in modo nativo. Ciò consente la creazione di un oggetto valore immutabile con molti campi senza dover ricorrere a setter o costruttori long illeggibili. Dal momento che la necessità di questo è altamente dipendente dalla lingua, non ha nulla a che fare con tutto ciò che riguarda Domain Driven Design. In tal caso, non è possibile utilizzare determinate lingue per DDD. Penso che DDD andrebbe bene fino a quando userai dei buoni nomi. Quindi no, non penso che il DDD proibisca l'uso dei costruttori.

Ricorda, fabbrica, costruttore o nuovo questo è il codice di costruzione. Non dovrebbe essere mescolato casualmente con il tuo codice comportamentale.

E ovviamente puoi usare le fabbriche con i costruttori per separare l'implementazione concreta dalla formula più astratta.

Nutrition secretFormula(Nutrition nutrition) {
    return nutrition
        .Builder(240, 8)
        .calories(100)
        .sodium(35)
        .carbohydrate(27)
        .build()
    ;
}

Nutrition dietFormula(Nutrition nutrition) {
    return nutrition
        .Builder(240, 8)
        .calories(0)
        .sodium(40)
        .carbohydrate(0)
        .build()
    ;
}

Penso che questo dimostri che il linguaggio ubiquitario può essere manifestato nei costruttori. Il tuo esperto di dominio dovrebbe essere in grado di leggerlo bene.