Come modellare una scatola con una chiave usando DDD?

Question

Come modellare una scatola con una chiave usando DDD?

#1 da (1 voti)

0

L'utente può creare una scatola con il testo all'interno. Quando viene creata una scatola, verrà assegnata una chiave (UUID). Questa chiave verrà quindi inviata al destinatario. Quando il destinatario attiva la chiave, riceve un messaggio nella casella corrispondente per inviare un'email.

Dato questo requisito ho trovato 2 radici aggregate: Box e Key

Ecco un flusso per la creazione di una scatola (senza errori)

CreateBox -> BoxCreated
BoxCreated -> CreateKey // handled by process manager
KeyCreated -> NotifyRecipient // handled by process manager

E il flusso di attivazione (senza esito negativo)

ActivateKey -> KeyActivated
KeyActivated -> OpenBox // handled by process manager
OpenBox -> BoxOpened
BoxOpened -> SendContentToRecipient // handled by process manager

Mi chiedo se è corretto approccio per modellare un sistema del genere?

Perché nell'architettura tradizionale incentrata sui dati avrei probabilmente solo un'entità Box con una proprietà key . E per attivare un tasto vorrei solo SELECT * FROM Box WHERE key = $key contrassegnarlo come attivato e salvarlo indietro.

domain-driven-design

posta Denis Mikhaylov 20.10.2015 - 20:20

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Posso eseguire una query in un blocco catch di try-catch? [duplicare] Il miglior pattern per scrivere una funzione PHP che controlla l'accesso e restituisce più boolean?

score 1 · Accepted Answer

Mi sembra che Box e Key facciano parte della stessa radice aggregata.

Use Cases:

When a user requests a box be built
Then a box is created
 And a key fitting the box is created
 And a recipient key is created

Given a created box
  And a created matching key
  And a recipient notification with key
 When a recipient uses the key from the notification
 Then the box is opened (seal is broken? key is broken?)
  And the content of the box is delivered

In tal caso, la radice aggregata (confine di consistenza) qui è il fabbro? :) La scatola e le chiavi sono emesse dal fabbro o dalla fabbrica di scatole.

Il flusso di lavoro di comandi / eventi potrebbe essere:

BuildBox (with contents) -> BoxCreated
                            KeyCreated (not sure if needed?)
                            RecipientKeyCreated

OpenBox (with Key) -> KeyConsumed (one-time use?)
                      BoxOpened
                      ContentsRemoved

DeliverKeyToRecipient -> (side effects like email)
                         KeyDeliveredToRecipient (if it's important to know)

// process manager
RecipientKeyCreated -> DeliverKeyToRecipient

Potresti provare a consegnare la chiave come parte del flusso di lavoro di box building, ma spesso tali preoccupazioni sono integrazioni esterne o altre politiche pratiche che desideri gestire al di fuori del dominio. Forse sono anche gestiti da un contesto limitato separato come Spedizione.