Devo avere un'interfaccia o una classe per la mia radice aggregata?

Question

Devo avere un'interfaccia o una classe per la mia radice aggregata?

#1 da (3 voti)

1

Vedi il codice qui

using System.Collections.Generic; 

 namespace DddInPractice.Logic.Common 
 { 
     public abstract class AggregateRoot
     { 
         private readonly List<IDomainEvent> _domainEvents = new List<IDomainEvent>(); 
         public virtual IReadOnlyList<IDomainEvent> DomainEvents => _domainEvents; 


         protected virtual void AddDomainEvent(IDomainEvent newEvent) 
         { 
             _domainEvents.Add(newEvent); 
         } 


         public virtual void ClearEvents() 
         { 
             _domainEvents.Clear(); 
         } 
     } 
 }

Sto discutendo se usare questa classe nel mio progetto. Mi piace l'idea perché incapsula Domain Events. Se lo utilizzo, tutte le classi Root di aggregazione ne deriveranno. In alternativa, potrei usare un'interfaccia marker come questa (che implementerà tutte le Root aggregate):

public interface IAggregateRoot
{
}

Dovrei:

Crea la classe base o
Crea l'interfaccia o
non fare né?

Mi piace l'idea di contrassegnare i miei Radici aggregati.

c# domain-driven-design

posta w0051977 01.02.2018 - 13:21

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design

Accoppiamento strutturale del test UML - Diagrammi del modello di classe di progettazione

score 3 · Accepted Answer

AggregateRoot , come Entity e Value , non è (di solito) parte della lingua ubiquitaria del tuo dominio. È veramente metadata , utile perché ti consente di esprimere la conoscenza del dominio in un modo agnostico del dominio, in modo che il tuo impianto idraulico generico possa fare qualcosa di utile con esso.

Come interfaccia marker ... beh, ad essere sincero, non vedo un sacco di valore aggiunto lì.

Come interfaccia di ruolo, comunica i metodi che devono essere implementati per agire nel ruolo. Questo, come notato sopra, può rendere più facile il riutilizzo del codice idraulico.

interface AggregateRoot {
    IReadOnlyList<IDomainEvent> changes();
    void clear();
}

E così potresti avere, per esempio

class HibernateCargo implements Cargo, AggregateRoot {
    // ...
}

puoi usare una classe base qui, ma trovo che sia meglio separare il contratto dall'implementazione.

abstract class AggregateBase implements AggregateRoot {
    // ... 
}

class HibernateCargo extends AggregateBase, implements Cargo {
    // ...
}