Come utilizzare DDD per risolvere una situazione di indirizzo comune?

Question

Come utilizzare DDD per risolvere una situazione di indirizzo comune?

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

0

Questo è un semplice esempio per mostrare una situazione che trovo difficile risolvere con DDD.

Considera questo: - Una proprietà (ad esempio una casa) ha un indirizzo. - Un indirizzo può essere completo o parziale (solo paese, paese e stato, paese, stato e città). - Quando un utente finale cerca proprietà, ho bisogno di visualizzare un elenco di tutti i paesi. - Quando viene selezionato un paese, devo recuperare tutti gli stati correlati. - Quando viene selezionato uno stato, ho bisogno di recuperare tutte le città correlate.

Questo può essere fatto facilmente usando un approccio basato sui dati (interrogando su un modello relazionale), ma quando provo a modellarlo, pensando a Domain Driven Design, sto fallendo.

Ho questo ovvio vincolo:

Una città non può esistere senza una proprietà.
Una proprietà non può esistere senza un paese.

Conclusione: il Paese è la radice aggregata per rafforzare questi vincoli.

Suppongo che l'indirizzo sia un'altra radice aggregata. Ma l'indirizzo può riferirsi solo ad una radice aggregata, quindi come posso riferire un indirizzo parziale? Devo pensare in un'altra radice? Quando ho bisogno di interrogare per città, ho bisogno di portare l'intera radice aggregata del paese? E se avessi bisogno di cercare tutte le città disponibili per una determinata stringa? Devo interrogare per tutti i paesi e non per le relazioni trasversali?

In questa situazione, la soluzione più ovvia per me è avere e aggregare root per città, stato, paese e indirizzo. Ma questo è un modello anemico. Ma per evitare un modello anemico, sembra che l'unico modo per risolvere sia avere modelli diversi. Uno per inserire nuove città (usando l'aggregato paese) e altre per recuperare e associare quelle entità. Ma questo ha un cattivo odore.

È molto difficile trovare un campione che copra una situazione come questa. Qualcuno può darmi delle indicazioni? Sto bene a raccomandare un libro, ma mi piacerebbe qualche intuizione diretta .

Ho letto molto su DDD e conosco la maggior parte dei termini (aggregato, entità, servizi, associazioni, oggetti valore).

domain-driven-design domain-model

posta Juliano 22.02.2015 - 12:53

fonte

2 risposte

0

Hai un buon modello per la gestione degli indirizzi. La relazione Stato / provincia (stato) ha funzionato bene per me. Non sono sicuro che funzioni per tutti i paesi. Per le applicazioni con cui ho lavorato, non sono stato in grado di normalizzare il campo cittadino. Ciò si traduce in tre tabelle con vincoli di chiave esterna in cascata.

country
state_province
address

La ricerca diventa complicata nel tuo caso, poiché probabilmente desideri abbinare casi in cui solo la nazione o il paese + stato vengono forniti durante la ricerca per città. Se non riesci a normalizzare la città, anche le ricerche per città saranno difficili.

risposta data 22.02.2015 - 22:29

fonte

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

biforcarsi ma non uscire Sapere chi è l'utente in ogni richiesta (ogni azione, ogni vista, ogni volta)

score 1 · Accepted Answer

La modellazione orientata agli oggetti, specialmente nel contesto della DDD, riguarda esclusivamente il comportamento. Stai parlando di un modello anemico, ma ho difficoltà a capire quale sarebbe il comportamento del paese / stato / città. Per lo più, sono solo possessori di dati.

C'è anche un conflitto nella tua narrativa. Stai dicendo che l'utente può ottenere un Paese o uno stato e, in base a ciò, ottenere i dati su una gerarchia più bassa. Non puoi farlo se paese e stato non hanno identità con cui identificarsi, nel senso che devono essere entità.

Nel tuo caso, non mi dispiacerebbe creare ognuno di questi come entità. È anche possibile creare una chiave composta per ciascuno. Ad esempio, la chiave della città sarà composta da {country_id, state_id, city_id} . Puoi anche far rispettare ciò consentendo solo di "aggiungere" nuovo stato attraverso il paese e la nuova città attraverso lo stato. Potrebbero creare la parte "contenente" della chiave lasciando l'ID figlio al motore di database.