Oggetti dominio con interfacce

Question

Oggetti dominio con interfacce

#1 da (2 voti)
#2 da (1 voti)

6

Mi trovo in una situazione in cui una parte del mio sistema ha una dipendenza da un altro modulo nello stesso sistema, ma i moduli stessi devono rimanere indipendentemente distribuibili, dove le parti da cui dipendono saranno riempite con un'altra implementazione.

Un modulo in questo caso è il concetto di un gruppo di componenti che contribuiscono tutti a servire una funzione aziendale. Il sistema è anche costruito in C #.

Quindi, dove dipendo da un altro modulo, il modulo sorgente definisce un'interfaccia che descrive le funzioni di cui ha bisogno il modulo del partito dipendente da implementare. I tipi di contratto (oggetti del modello di dominio) sono anche interfacce per il modulo dipendente.

Ecco dove diventa un po 'confuso per me. Il principio di inversione di dipendenza non si trova bene nella mia testa a questo punto. Entrambi questi "moduli" hanno la stessa importanza l'uno dell'altro. Quale dovrebbe definire le interfacce e forzare l'altro a farvi riferimento? Sospetto che un terzo progetto sia inserito tra i moduli che gestiscono l'impostazione delle dipendenze (probabilmente un contenitore DI). Le entità dei moduli dovrebbero essere interfacciate? Sono semplicemente sacchetti di get / set (non DDD qui).

Qualcuno può offrire una guida qui?

Grazie in anticipo.

Modifica 1:

La struttura del progetto:

Module1.Interfaces
   IModuleOneServices
Module1.Models
   ModuleOneDataObject
Module1
   Module1 implements IModuleOneServices

Module2.Interfaces
   IModuleTwoServices

Module2.Models
   ModuleTwoDataObject - has property of type ModuleOneDataObject

Module2
   Module2 implements IModuleTwoServices
       depends on IModuleOneServices

Il modulo2 deve essere distribuibile da solo, e rimane compilabile, e talvolta può essere eseguito senza presentare Module1.

domain-driven-design architecture n-tier

posta Martin Blore 31.07.2012 - 21:47

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design architecture n-tier

SDK multipiattaforma mobile per app ad uso intensivo di calcolo [chiuso] Esecuzione di chiamate API di Twitter autorizzate OAuth lato client rispetto al lato server, quanta differenza c'è in termini di prestazioni?

score 2 · Answer 1

Hmm, sembra che tu abbia bisogno di un modulo di colla. Che ne dici di un orchestratore che conosce entrambi i moduli e può mediare tra loro? I moduli stessi non hanno bisogno di conoscersi allora.

Un'altra opzione consiste nel mettere le classi "condivise" in una libreria condivisa su cui entrambi i moduli possono fare affidamento.

Questa non è esattamente inversione di dipendenza, ma perché dovresti seguire questo approccio dogmaticamente. Sospetto che tu stia costruendo un'applicazione con questi due moduli, quindi un approccio top-down va bene qui imho.

score 1 · Answer 2

Il principio di inversione delle dipendenze si applica molto bene a ciò che stai cercando di fare.

Lasciatemi esemplificare. Se A usa B, allora A dipende da B. Per frenare la dipendenza, si introduce un'interfaccia. L'interfaccia deve appartenere al pacchetto A e può essere implementata da B o C o qualsiasi altro modulo. La parte importante qui è l'appartenenza ad A. Se lo fai, puoi distribuire A senza distribuire o ricompilare B. A dipende da un'interfaccia, che è la cosa più astratta che puoi avere in OO. A seconda delle cose astratte è anche il meglio che puoi fare.

Ora, questo risolve il problema dove A usa B. Se ti capisco correttamente, il tuo modulo B usa anche A. Quindi hai anche una dipendenza inversa. Questa dipendenza ciclica dovrebbe essere evitata quando possibile. Tuttavia, se succede, basta creare un'interfaccia appartenente a B e implementata da A. Fai il contrario del mio paragrafo precedente.

In questo modo puoi distribuire ciascuno dei tuoi moduli in modo indipendente. L'unica ragione per implementare entrambi è quando cambi l'interfaccia in modo tale che non sia più compatibile con le versioni precedenti.