DDD che integra radice aggregata con servizio host aperto (OHS)

Question

DDD che integra radice aggregata con servizio host aperto (OHS)

#1 da (3 voti)

0

Ecco il caso: secondo il linguaggio ubiquitario - il pagamento può essere inviato per l'elaborazione al gateway di pagamento (che si trova in un contesto limitato integrato tramite ACL (strato anti-corruzione) + OHS / PL)

In contesto locale, il pagamento è radice aggregata, quindi mi aspetterei un design del genere:

payment.send();

ma il problema qui è che il pagamento deve sapere come inviare il suo stato ad un altro contesto limitato tramite ACL a OHS. Quindi ho bisogno di iniettare questo PaymentGatewayService / Adapter come argomento:

payment.send(paymentGatewayService);

In questo caso paymentGatewayService restituisce alcuni oggetti valore che possono essere elaborati con il pagamento all'interno del metodo send() . Ma Ho sentito che questa non è una buona pratica per iniettare servizi per aggregare la radice tramite argomenti del metodo o DI, ma forse è OK? Il vantaggio qui è che non espongo la struttura aggregata all'esterno. O dovrei creare un servizio di dominio per coprirlo come:

Payment payment = ...
payment = paymentGatewayService.send(payment);
paymentRepository.store(payment);

In questo caso, non mi piace questa inversione, perché devo esporre direttamente la struttura aggregata in modo che il servizio gateway possa tradurre nel suo modello. Anche questo sta causando anemia in aggregato di pagamento.

Come posso gestire correttamente tali situazioni ??

domain-driven-design domain-model aggregate

posta Slimer 29.09.2017 - 09:07

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design domain-model aggregate

Cosa devo considerare quando aggiungo una condizione a una funzione esistente? [chiuso] Parametro API per "includere" risolvendo gli ID sugli oggetti

score 3 · Accepted Answer

But I heard that this is not quite good practice to inject services to aggregate root via method arguments or DI, but maybe it's OK?

Ci sono trade off.

Evans descrive servizi di dominio come costrutto per servire questo ruolo. Quindi passiamo all'aggregato un adattatore che esprime il concetto di gateway nella lingua del dominio , in modo che il modello possa interagire con esso. L'implementazione sottostante del servizio di dominio probabilmente delegherà il lavoro effettivo a un servizio applicativo oa un servizio di infrastruttura.

Quindi, fatto correttamente, è completamente coerente con l'approccio focalizzato sul dominio.

Ma introduce qualche accoppiamento tra l'effetto collaterale e l'aggregato che potresti non volere

le modalità di errore dell'effetto collaterale ora passano attraverso l'aggregato
l'aggregato e l'effetto collaterale sono accoppiati nel tempo

Diamo un'occhiata più attenta sotto le copertine del tuo primo esempio

payment.send(paymentGatewayService);

E prova a suddividere esplicitamente cosa sta succedendo

Payment::send(paymentGatewayService):
    x = this.getCurrentState()
    m = createPaymentMessage(x)
    y = paymentGatewayService.send(m)
    z = calculateNewState(x, y, m)
    this.setState(z)

Il che significa che ciò che abbiamo qui sono tre passaggi

abbiamo query l'aggregato per scoprire il messaggio appropriato da inviare, senza toccare il gateway di pagamento
abbiamo invia il messaggio al gateway di pagamento, senza toccare l'aggregato
noi aggiorniamo l'aggregato usando la risposta dal gateway come input

e il compromesso è: vogliamo quegli effetti collaterali nell'aggregato, nell'applicazione, o eventualmente nascosto in un servizio di dominio diverso che è responsabile per il coordinamento?

PaymentProtocol::send(payment, paymentGateway):
    m = payment.createPaymentMessage()
    y = paymentGatewayService.send(m)
    payment.onPaymentSent(y)

In questa progettazione, il protocollo di pagamento orchestra gli effetti collaterali sul pagamento e sul gateway di pagamento. Questo ti dà un aggregato pulito (la sua responsabilità è mantenere la propria invariante) e mantiene tutto il processo in un unico posto.

In this case, I don't really like this inversion, because I must directly expose aggregate structure so gateway service can translate to its model. Also this is causing anemia in payment aggregate.

Non è giusto - l'aggregato è ancora completamente responsabile del mantenimento della propria invariante; è semplicemente assolto dalla responsabilità di gestire un effetto collaterale a cui è interessato. L'aggregato è mai che espone la propria struttura, espone sempre e solo un messaggio che lo ha creato utilizzando la sua stessa struttura.

Va comunque bene non come , ovviamente.