DDD: esiste un posto per "trova o crea" nella logica aziendale

Question

DDD: esiste un posto per "trova o crea" nella logica aziendale

#1 da (2 voti)
#2 da (1 voti)

1

Alcune azioni dell'utente portano naturalmente a situazioni di ricerca o creazione. Ad esempio, l'utente accede a un sistema con un metodo alternativo e find-or-create è chiamato invia email. Oppure, un altro esempio, l'utente viene creato con l'email dell'acquirente. Ma ovviamente, se c'è già un utente, quell'azione provoca il find-or-create. Alcuni database (pensate a loro come basi per i repository di DDD) hanno anche funzionalità avanzate per questi casi.

D'altra parte, ritengo che la ricerca o la creazione non sia veramente un'azione di dominio aziendale. Ovviamente, qui è conservato un invariante di sistema (per uno degli esempi precedenti: "ogni acquirente dovrebbe avere un utente, identificato tramite e-mail").

Potrebbe esserci anche un altro comportamento nel mezzo "se non esiste, creare, quindi restituire esistente". Ad esempio, la registrazione: dobbiamo registrare la creazione separatamente? Annulla: solo "trova" non contiene nulla da annullare, a differenza di "crea"; possono esserci anche altri aspetti, che entrano in gioco nella parte "crea" o solo nella parte "trova", o in entrambi.

Dato questo, come trovare find-or-create dovrebbe essere compreso in DDD (design basato sul dominio)? È un'operazione di basso livello o parte della logica del dominio?

Sono a conoscenza dei dibattiti su quanta logica aziendale dovrebbe vivere nel database per motivi di integrità, questa domanda non riguarda questo. In qualsiasi implementazione pratica le azioni sono suddivise in sotto-azioni (ad esempio, come uno script di transazione). La domanda è se find-or-create è solitamente parte dell'attività o del livello di accesso ai dati sottostante? O forse questo è un esempio di un servizio molto semplice?

domain-driven-design patterns-and-practices

posta Roman Susi 26.05.2018 - 19:34

fonte

2 risposte

1

Ho l'impressione che tu stia pensando troppo a questo. Il codice che implementa la logica di business è in in tutti i livelli del tuo sistema . Certo, DDD sostiene che la logica di base dovrebbe essere nel "livello dominio", tuttavia la maggior parte degli ingegneri del software non esita a implementare determinate funzionalità direttamente nel database (come vincoli, indici univoci, viste con query specifiche e talvolta anche stored procedure). Inoltre, nell'interfaccia utente esiste sempre una logica dell'interfaccia utente, che riporta la logica nei report, tutti causati dai requisiti aziendali.

Quindi, se il livello di accesso ai dati fornisce qualcosa come un "upsert" come operazione di base, e hai alcuni requisiti aziendali in cui può essere utilizzato in modo ragionevole, quindi utilizzalo - certo che è un'implementazione della logica aziendale, ma non più o meno giustificato degli altri casi che ho menzionato in cui trovi BL fuori dal livello del dominio.

risposta data 26.05.2018 - 22:25

fonte

Leggi altre domande sui tag domain-driven-design patterns-and-practices

In difficoltà con l'implementazione della sincronizzazione o della concorrenza Progettazione del database: dove archiviare un flag "corrente" o "selezionato" in una gerarchia padre-figlio [duplicato]

score 2 · Accepted Answer

Given this, how find-or-create should be understood in DDD (domain-driven design)? Is it low-level operation or part of domain logic?

Nei domini chiave (nei luoghi in cui stiamo facendo ddd perché è qui che ricaviamo un vantaggio competitivo), penso che voglia essere parte della logica del dominio.

Il che significa che l'interfaccia del repository dovrebbe essere comprensibile per avere la semantica di

Identifier -> Maybe<Aggregate>

Spesso descriviamo i comportamenti come se il tempo fosse assoluto e la messaggistica fosse affidabile. Ma quell'astrazione non regge particolarmente bene nel mondo reale, e certamente non nel mondo digitale distribuito. Se l'astrazione non regge, allora preferirei essere esplicito sul fatto che non lo è.

Personalmente, divento un po 'nervoso all'idea che cose magiche accadano quando il modello di dominio e il database non sono d'accordo sullo stato del mondo.