Tabelle di ricerca: sono una perdita nel modello di dominio?

Question

Tabelle di ricerca: sono una perdita nel modello di dominio?

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

10

Stai costruendo un sistema che tiene traccia delle Aziende. Quelle aziende hanno contatti. Questi contatti sono spesso specialisti che rispondono solo a determinati tipi di domande, ad esempio Fatturazione / Pagamento, Vendite, Ordini e Assistenza clienti.

Usando Domain Driven Design e una Onion Architecture, ho modellato questo con il seguenti tipi:

società
- Ha contatti
contatto
- Ha tipi di contatto
ContactType (enum)
CompanyRepository (interfaccia)
EFCompanyRepository (definito in un assembly esterno, utilizza EntityFramework, implementa CompanyRepository)

Il nostro team ha un'opinione divisa su come modellare il database per questa applicazione.

Lato A: DDDer magra:

È compito del dominio definire quali ContactTypes sono validi per un contatto. L'aggiunta di una tabella al database per convalidare che ContactTypes sconosciuto non è stato salvato è un segno di un dominio che perde. Si diffonde la logica troppo in là.
L'aggiunta di una tabella statica al database e il codice corrispondente sono inutili. In questa applicazione il database risolve un problema: persistere la cosa e restituirla a me. Scrivere una tabella in più e il codice CRUD corrispondente è uno spreco.
Cambiare la strategia per la persistenza dovrebbe essere il più semplice possibile. È più probabile che cambi le regole aziendali. Se decido che SQL Server costa troppo, non voglio dover ricostruire tutta la validazione che ho inserito nel mio schema.

Lato B: i tradizionalisti [che probabilmente non è un nome giusto. I DBCentrists?]:

È una cattiva idea avere dati nel database che non hanno senso senza leggere il codice. Rapporti e altri utenti devono ripetere l'elenco di valori.
Non è tanto il codice per caricare i dizionari di tipo db su richiesta. Non preoccuparti per questo.
Se l'origine di questo è codice e non dati, dovrò distribuire bit anziché un semplice script SQL quando cambierà.

Nessuna delle due parti è giusta o sbagliata, ma una di queste è probabilmente più efficiente a lungo termine, contando i tempi di sviluppo per lo sviluppo iniziale, i bug, ecc. Di che lato si tratta - o c'è un compromesso migliore? Cosa fanno gli altri team che scrivono questo stile di codice?

domain-driven-design domain-model onion-architecture

posta Drew 27.10.2015 - 14:14

fonte

4 risposte

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

Flusso di lavoro GIT per singolo sviluppatore (passaggio da semplice FTP) Python Multiprocessing con Queue vs ZeroMQ IPC

score 3 · Answer 1

Adottando l'architettura DDD e cipolla, hai deciso che il database è secondo al tuo modello di dominio. Ciò significa che non ci sarà nessun altro a fare operazioni sul database oltre al modello. In primo luogo, i tradizionalisti non avrebbero gradito l'uso del DDD.

La prima cosa è chiara: hai bisogno della "tabella di ricerca" nel modello. Il modello deve differenziare tra diversi tipi di contatti. Ciò significa che mantiene una lista strongmente tipizzata di tutti i tipi. È inoltre necessario mappare da quei tipi forti a valori che sono serializzati su database. Questa mappatura può essere all'interno del modulo del database. Ma l'elenco di tutti i possibili tipi sarà ancora nel modello. E se il modello deve essere un'unica fonte di verità, allora non può essere all'interno del database. O almeno, quando la lista cambia nel modello, deve cambiare nel database. E no ma!

score 2 · Answer 2

Gli oggetti dominio smettono di essere oggetti dominio quando attraversano un limite di processo . Anche se il database è solo un archivio di persistenza, a un certo punto in futuro le richieste del business causeranno una modifica al modello domaim che è incoerente con la cronologia persistente, e avrete comunque bisogno di un livello anti corruzione ....

Detto questo, penso che i tuoi DBCentrists manchino alla barca. I modellatori di domini stanno dicendo che hanno bisogno di un archivio di persistenza. "I report e gli altri consumatori" hanno bisogno di qualcosa che possono interrogare, qualcosa con indici decenti, come è stato notato nei commenti.

Chi ha introdotto il vincolo che tutte queste diverse preoccupazioni dovevano essere supportate dal un database? Cosa succede se te lo restituisci.

Parola chiave di ricerca: CQRS.

score 1 · Answer 3

Ho trovato il modo migliore per memorizzare le enumerazioni come rappresentazione delle stringhe nel database e non includere una tabella di ricerca.

Ovviamente il lato negativo di questo è che utilizza più spazio su disco e non è normalizzato.

Il lato positivo è che il campo mantiene il suo significato nel db, non si finisce con numeri magici corrosivi al valore int dell'enum per esempio e non si deve gestire il controllo della versione di una tabella di ricerca quando l'enum cambia.

Non sono sicuro che lo definirei come una differenza tra DDD e Trad. Più è nel mio punto di vista un codice database-centralista vs

score 0 · Answer 4

Finché si utilizza un database relazionale, è necessario mantenere le tabelle normalizzate in misura ragionevole. La normalizzazione aiuta a prevenire l'inserimento e ad aggiornare le anomalie.
La relazione one-app < - > one-database non è più comune, più app possono utilizzare più database e un singolo database può essere utilizzato da più app, quindi avere il database impone l'integrità referenziale il più possibile è buona .
RDBMS è tuo amico.
Puoi invece utilizzare una memoria con valori-chiave e fare tutto nel codice.