Oggetto valore che dipende dal ciclo di vita di più aggregati in DDD

3

Durante la prototipazione di una semplice applicazione ddd dal dominio di transito pubblico ho riscontrato un problema con un oggetto valore - Transit Pass:

Ogni cliente può acquistare una percentuale di transito% co_de che consente a un passeggero del servizio di prendere un certo numero di viaggi pre-acquistati o viaggi illimitati entro un determinato periodo di tempo. Una descrizione dettagliata di questi passaggi è rappresentata in casi di Pass s. Un cliente seleziona PassDefinition che è più appropriato per lui e riceve un nuovo PassDefinition .

Nella parola reale, Customer Pass ha Account es quindi è abbastanza semplice mettere Pass in Pass aggregato come oggetto valore che ha un puntatore a Account . Questo approccio ha 2 problemi:

  • Che cosa succede se l'amministratore eliminerà PassDefinition ? Alcuni oggetti PassDefinition potrebbero puntare a Pass cancellato e l'inconsistenza nel contesto si presenterà.
  • Ci sarà un metodo (hasEligiblePass) su PassDefinition e dal momento che Account non ha informazioni sulla validità, sarà richiesta la chiamata esterna di vehicleAllowed etc a Pass .

Un'altra opzione è spostare PassDefinition in Pass aggregato. Ma:

  • Che cosa succede se il Cliente eliminerà PassDefinition (mentre è improbabile dal momento che l'account può essere attivato / disattivato solo dal progetto)?
  • È un'operazione molto comune nel sistema elencare tutti i Account es disponibili per lo specifico Pass . Mettere Account in Pass costringerà tale operazione banale a recuperare PassDefinition s e filtrerà molti risultati.

Quindi il problema globale è che il% ciclo di vita di PassDefinition dipende da Pass e Account cicli di vita. Come gestire tali oggetti in DDD?

    
posta ovnia 14.12.2016 - 13:18
fonte

2 risposte

5

PassDefinition sembra sospettosamente un nome inventato da un programmatore, piuttosto che qualcosa preso dal linguaggio ubiquo. Dovresti probabilmente sederti con i tuoi esperti di dominio e capire cosa sta realmente accadendo nel business.

Suppongo che tu stia confondendo due (o più) concetti: quello del contratto stabilito quando un cliente acquista un pass e quello dell'offerta nel catalogo di vendita quando il cliente considera un acquisto.

Affrontare il problema mentre lo presenti: è abbastanza comune avere uno stato che faccia riferimento a due aggregati diversi. Questo di solito significa un altro aggregato con un proprio ciclo di vita che rappresenta la relazione tra gli aggregati.

Naturalmente, in un tale progetto le modifiche all'aggregato nel mezzo sono isolate dallo stato corrente di ciascuno degli aggregati di riferimento. Tutto lo stato richiesto per convalidare una modifica al modello deve essere in un unico posto.

    
risposta data 14.12.2016 - 14:55
fonte
1

Se metti CustomerId su Pass e lo sposti con PassDefinition puoi avere

PassDomain.Pass
PassDomain.PassDefinition
PassDomain.PassRepository

PassRepository.GetValidPassFor(customerId,vehicleType,journeyDate)

Forse dividi customerId in ownerId + ownerType per evitare il presunto collegamento al Cliente

    
risposta data 14.12.2016 - 13:27
fonte