Come si definisce un singolo metodo generico per applicare eventi sottotipi di una classe base?

Questo è semplicemente modello di strategia con un parametro aggiuntivo per il "contesto" passato alla strategia, come in questa domanda SO . Ne risulta un accoppiamento stretto e bidirezionale tra OrderEvent e Order (che potrebbe andare bene per questo caso). Se ogni oggetto OrderEvent è sempre associato allo stesso oggetto Order , passa meglio this (l'oggetto Order ) come parametro costruttore nel relativo OrderEvent , puoi salvare il parametro in applyTo metodo allora (comunque, l'accoppiamento rimarrà). Se lo stesso OrderEvent può essere applicato a diversi ordini, la soluzione va bene.

P.S: questo non è in nessun modo speciale per DDD, CQRS, o event-sourcing, quindi penso che i tuoi tag di domanda non si adattino bene.

Sfortunatamente Java non supporta invio multiplo ma puoi usare la riflessione per chiamare il metodo appropriato senza rompere il principio di chiusura aperta o introdurre una dipendenza accidentale tra eventi e aggregati.

Pertanto, potresti utilizzare un dispatcher che identifica il giusto metodo apply e quindi chiamarlo:

class Dispatcher {
   public void applyEvent(Object aggregate, Object event) {
      Method m = aggregate.getClass().getDeclaredMethod('apply',new Class[](event.getClass());
      m.invoke(aggregate,new Object[](event);
   }
}

Come usi questo componente? (ad esempio potresti adattarlo per essere una classe base che le radici Aggregate ereditano da esso).

Scusami se capisco male il contesto del tuo bisogno qui, ma quello che capisco è che devi applicare un'implementazione diversa a ciascun evento in base a quale sottoclasse è stato costruito da. In generale, ogni volta che devo ricorrere a instance of e sovraccaricare il metodo apply, ad esempio per ogni sottoclasse, mi fa tornare alla scheda di progettazione perché significa che ho fatto qualcosa di sbagliato.

Secondo me dovresti rendere le firme del metodo generico (come applicare, fare, ottenere, impostare ecc.) che tutti gli oggetti evento dell'ordine delegato dovrebbero avere, un'interfaccia o una super classe con detti metodi come abstract (per forzare le sottoclassi per implementarli). Quindi implementa questo in ogni sottoclasse OrderEvent per differenziare il comportamento nel modo desiderato. Quindi si tratta dei singoli metodi di applicazione con un oggetto Interface o super Class come argomento e quindi semplicemente chiamando il metodo generico appropriato all'interno del metodo apply, il compilatore saprà in fase di esecuzione quale tipo di oggetto si possiede e chiamerà il metodo appropriato per questo allora.

Per visualizzarlo un po 'meglio, considera questo:

interface OrderEvent{
(abstract)do();get();set();
}
class OrderCancelled implements or extends OrderEvent{
do(){ logic;} get(){logic;} set(){logic;}
}
class CompositeOrderWithDelegate(){
 apply(OrderEvent oe){
  oe.do();
 ...
 }
}

Il secondo approccio è buono, anche se in questo momento questo porterà a un ciclo. Quello che devi fare è inserire la vera logica dell'evento nell'evento.

Ora fai

class OrderPlaced extends OrderEvent {
    void applyTo(Order order) {
        order.apply(this);
    }
}

Che cosa dovresti fare imo

class OrderPlaced extends OrderEvent {
    void applyTo(Order order) {
        //real logic what happens in order class happens here now
        order.setDate(date);
        order.doThis(var1);
        order.doThat(var2);
    }
}

Quindi solo i tuoi OrderEvents sanno come vengono applicati all'Ordine e la tua classe Order non sa nulla. Ora puoi creare tutte le sottoclassi di OrderEvent che desideri senza toccare di nuovo la classe Order.

What's the common pattern used for this?

Hai davvero scoperto entrambi i pattern principali utilizzati.

It results in a more concise code, but I'm not so sure about the almost circular nature of the approach.

Sì, questo è un odore di codice.

In breve, hai preso la decisione che tutti questi eventi estendano una radice comune, il che va bene. Ma hai lasciato che la decisione sugli eventi si diffondesse nell'Ordine. Non è così bello.

Nascondere le decisioni nei moduli è una parte importante delle modifiche al codice facile. Vuoi ridurre al minimo il numero di luoghi che sono intimi con una decisione in modo da essere libero di cambiarlo più tardi.

Il design sotto è analogo a quello che stai facendo ora

class API {
    interface OrderEvent {
        void applyTo(Order order);
    }
    interface OrderPlaced extends OrderEvent {
        // ...
    }
}
class Data {
    class OrderPlaced implements API.OrderPlaced {
        public void applyTo(Order order) {

        }
    }
}

Ma mette in difficoltà le tue preoccupazioni; chiunque abbia bisogno di sapere su OrderPlaced deve anche conoscere applyTo , il che non ha senso dal momento che lo sono mai usare queste informazioni per niente.

Confronta con:

class API {
    interface OrderPlaced {
        // ...
    }
}
class History {
    interface OrderEvent {
        void applyTo(Order order);
    }
}
class Data {
    class OrderPlaced implements API.OrderPlaced, History.OrderEvent {
        public void applyTo(Order order) {

        }
    }
}

Il codice che conosce raccolte eterogenee di eventi dell'ordine richiede l'interfaccia History.OrderEvent, ma non ha bisogno di sapere nulla su OrderPlaced o sui dettagli di implementazione. L'ordine deve sapere su API.OrderPlaced, ma nulla sul fatto che gli ordini siano generici.

Qualsiasi cosa direttamente accoppiata all'implementazione (la classe stessa, la fabbrica che invoca il suo costruttore), ovviamente, deve conoscere l'intera verità.