Un aggregato senza una radice aggregata?

0

Questo non è un problema che sto avendo nel mio dominio problematico. È solo un esercizio di pensiero.

Dire che ho una calcolatrice semplice come questa:

public class Calculator
{
     public IEnumerable<KeyValuePair<int, int>> CalculateDenominationsFor(int cost) 
            {
                var target = cost;
                foreach (var denomination in currency.AvailableDenominations.OrderByDescending(a => a))
                {
                   var numberRequired = target / denomination;
                   if (numberRequired > 0)    
             {
                   yield return new KeyValuePair<int, int>(denomination, numberRequired);
               }
               target = target - (numberRequired * denomination); 
            }
    } 
}

Allo stato attuale non vi è alcuna Entità e nessuna radice Aggrega.

Credo di avere due opzioni:

  1. Nessuna radice aggregata: chiedere al servizio dell'applicazione di chiamare direttamente il servizio di dominio, cioè fornire un costo e ricevere le denominazioni.

  2. Introduci una radice aggregata: crea una classe chiamata ChangeRequest come la seguente:

    public class ChangeRequest
    {
        public decimal Cost {get; set;}
        public listKeyValuePair<int, int> denominations {get; set;}
    
       public IEnumerable<KeyValuePair<int, int>> AddDenominations(Calculator calculator)
       {
         //Add denominations to list here.
       }
    }
    

È normale avere un aggregato senza una radice aggregata?

    
posta w0051977 30.01.2018 - 21:13
fonte

2 risposte

4

Iniziamo con un modulo di preventivo Evans nel suo libro di riferimento DDD:

Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation.

Tenendo presente questo, possiamo ora esaminare le definizioni DDD:

AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes.

SERVICE: An operation offered as an interface that stands alone in the model, with no encapsulated state.

Calculator non ha dati e nessuno stato. Quindi non esiste uno scopo di modifica dei dati . Di conseguenza, non esiste alcun aggregato. T

L'operazione CalculateDenominationsFor() è offerta come parte dell'interfaccia di Calculator . La classe si trova da sola nel modello e non ha uno stato incapsulato. Il suo unico scopo è l'esecuzione dell'operazione. Di conseguenza è un servizio.

L'aggiunta di una radice di aggregazione fittizia, solo perché il servizio è esposto tramite un oggetto, sembra un'ingegneria eccessiva.

Tuttavia c'è ancora margine di miglioramento: il metodo non dipende da alcuna istanza di oggetto, quindi potresti dichiararlo come static . Se tutti i membri di quella classe sono statici, è possibile dichiarare la classe stessa come static . Questo ha il vantaggio di evidenziare la vera natura di quella classe.

    
risposta data 30.01.2018 - 23:16
fonte
0

Consentitemi di riformulare la domanda in "se è comune o meno che il servizio applicazioni non stia consumando il servizio di dominio direttamente?" Sì, è comune.

Un esempio live sta autenticando l'utente nell'IDDD di Vaughn Vernon. Il codice sorgente è qui .

L'autore ha confrontato profondamente due implementazioni nel capitolo del servizio di dominio del libro IDDD. Il primo tentativo consiste nell'utilizzare le entità direttamente in Application Service senza introdurre Domain Service. Il problema principale è che rende superfluo l'Application Service (il client degli oggetti di dominio) e non è necessario conoscere l'interno degli oggetti del dominio.

Per farla breve, utilizzare il servizio di dominio direttamente nel servizio di applicazione è molto utile quando si serve lo scenario di richiesta.

    
risposta data 30.01.2018 - 23:56
fonte

Leggi altre domande sui tag