Credo di capire il tuo dilemma.
Anche se può essere uno spreco reidratare l'intero aggregato per questo, l'aggregato serve allo scopo specifico di essere il confine di consistenza. Se avessi un sottoinsieme del dominio solo per gestire le offerte e l'aggregato completo per altre operazioni, come manterrai la coerenza quando hai potenzialmente due operazioni di manutenzione degli oggetti sullo stesso AR? Non hai più un singolo confine di consistenza. Sei sicuro che le prestazioni saranno un problema se reidratare l'intera cosa per questa operazione minore? L'hai misurato?
Se diventa un problema, una cosa che puoi fare è spostare i casi d'uso su un livello in modo che vengano intercettati prima che la radice aggregata sia caricata. Questo è comune nei sistemi basati su messaggistica in cui si impartiscono comandi al dominio (non si chiama un metodo direttamente su un aggregato caricato). I comandi vengono ricevuti dagli handler, che idratano l'aggregato come appropriato per il caso d'uso (ad esempio una versione cancellata dell'aggregato che si rifiuta di eseguire qualsiasi operazione dal momento in cui viene cancellata, o nel tuo caso una versione limitata che accetta solo le offerte). A volte i gestori caricano anche altri aggregati (solo per informazione, altrimenti il confine di consistenza viene violato di nuovo) o preparano i servizi da consegnare all'aggregato per eseguire il caso d'uso specificato.
In un sistema di messaggistica non in linea puoi ottenere lo stesso risultato con il Pattern di facciata . In sostanza, si crea un oggetto che è la tua interfaccia nel dominio. L'oggetto ha un metodo per caso d'uso. All'interno di quel metodo, si esegue il codice del gestore; idratare l'aggregato appropriato, scambiare le risorse / servizi necessari per il caso dell'utente e chiamare il metodo dell'aggregato. Forse salva anche le modifiche. Alla fine, è possibile ottenere troppi parametri sui metodi di facciata e sarà necessario rifattorizzarli su un oggetto. A quel punto, hai un messaggio di comando come parametro. :)
Tuttavia, se fai qualcosa di simile hai bisogno di alcune garanzie infrastrutturali. Ad esempio, un aggregato specifico può eseguire solo un caso di utilizzo alla volta. La mia prima infrastruttura come questa, ogni tipo di aggregato (non ogni istanza) poteva eseguire solo un caso d'uso alla volta - in altre parole se avessi inviato 100 operazioni, ciascuna a un'asta diversa, sarebbero comunque state eseguite una alla volta . In pratica, non si trattava di un problema di prestazioni, in quanto di solito si verificano più problemi di I / O rispetto alle operazioni di dominio.