2013-03-08 16 views
5

Mi piacerebbe sapere come implementare le fabbriche nella progettazione basata sul dominio. (esempi)DDD - Come implementare le fabbriche

Dove dovrebbero essere posizionate le interfacce e le implementazioni delle fabbriche? Devo creare interfacce per gli oggetti Dominio che le fabbriche creano? Devo creare fabbriche per repository, servizi, ...

Uso i contenitori di iniezione di dipendenza come posso metterli insieme alle fabbriche?

Grazie.

+2

imho questa domanda è chiusa in modo errato dal momento che parlare di fabbriche in DDD limita abbastanza bene rispetto a parlare di fabbriche in generale. come imilarli è una buona domanda poiché ci sono tipicamente tre approcci: fabbriche separate, lasciando che i repository agiscano come fabbriche o semplicemente "nuove" le entità di dominio. – jgauffin

+0

Tuttavia, non mescolare le domande sulle entità di dominio in generale, poiché rende la domanda ambigua. Tenerlo specifico o creare più domande. – jgauffin

risposta

10

Le fabbriche devono essere classi semplici, in genere statiche. Possono anche essere implementati come metodi statici sull'entità o sull'oggetto valore che creano. Le fabbriche dovrebbero creare oggetti di dominio direttamente e solo oggetti di dominio. Inoltre, le fabbriche non dovrebbero essere legate all'iniezione delle dipendenze perché gli oggetti del dominio non dovrebbero avere delle dipendenze iniettate in essi.

Gli oggetti del dominio non devono implementare le interfacce, ovvero un'astrazione inutile.

I servizi e le implementazioni di repository hanno invece dipendenze e devono essere creati dal contenitore DI.

+2

Le interfacce sono in realtà un'astrazione inutile se si lavora da soli per sviluppare un prototipo monouso (nessuna evoluzione prevista e quindi nessun test). Su domini complessi con una grande squadra di persone che lavorano su diversi livelli, le interfacce consentono un'efficace parallelizzazione dei refactoring dopo le modifiche del dominio. Inoltre, senza interfacce, un corretto test dell'unità diventa molto più difficile. –

+2

In particolare per gli oggetti di dominio, le interfacce non sono solo un'astrazione inutile, sono un'astrazione dannosa. Le interfacce per servizi o repository d'altra parte sono certamente preziose. Tuttavia, dichiarare le interfacce per i test da solo può essere evitato con un bel quadro di derisione. In generale, desidero solo evidenziare il costo dell'astrazione. In primo luogo, si impara il valore dell'astrazione, quindi il costo. – eulerfx

+0

Concordo sul fatto che nella maggior parte dei casi gli oggetti di dominio tipici non necessitano di interfacce diverse da quelle menzionate. Ma come sempre dipende dal dominio :) Se ci sono oggetti generici che possono essere scambiati (strategie) nel tuo dominio, allora potrebbe essere utile o addirittura necessario. Ma immagino che sarebbe un'eccezione. –

Problemi correlati