DDD: come risolvere i membri aggregati che necessitano di dipendenze?

Ho il seguente aggregato:

• Checkout (root)
• Requisito: rimborso del coupon, altro requisito, tuttavia un altro requisito
• Coupon

Un Checkout ha molti requisiti che devono essere soddisfatti per poter completare un Checkout . Ogni Requirement ha un metodo fulfill(data) responsabile del processo di evasione degli ordini.

Uno di questi requisiti è un CouponRequirement che, una volta completato, deve essere sicuro che ci sia uno stock per un particolare coupon e riservarlo. Perché ciò accada, ho bisogno di accedere a CouponRepository o CouponService .

Come potrei personalizzare il mio progetto per soddisfare tale dipendenza?

FulfillRequirementCommand

function handle($cmd) {
   $cho = $this->checkoutRepository->get($cmd->checkoutId);
   $cho->fulfillRequirement($cmd->requirementType, $cmd->requirementData);
}

Checkout

function fulfillRequirement($reqType, $reqData) {
    $req = $this->getRequirement($reqType);
    $req->fulfill($reqData);
}

CouponRequirement

function fulfill($data) {
    // check stock / reserve coupon
}

La soluzione comune sarebbe passare un CouponService a fulfillRequirement. Ma fulfillRequirement si prende cura di molti tipi di Requisito, non solo uno.

Forse ho solo bisogno di abbandonare l'approccio generico e avere più fulfillRequirement :

fulfillCouponRequirement($data, $couponService) fulfillClientInformationRequirement($data)

.. ecc.

Che cosa ne pensate voi ragazzi? anche se pensi ad un approccio diverso, mi piacerebbe leggerlo.