7
Fare alcune ricerche per ottenere un progetto CouchApp.CouchDB/NoSQL e Domain Driven Design?
Ho compreso il concetto di Document Data Store rispetto a un RDBMS regolare. E posso afferrare totalmente i documenti e le viste di modellazione invece di usare le istruzioni WHERE e JOIN. Ma non sono stato in grado di trovare molte risorse su come modellare documenti, viste e documenti di progettazione con Domain Driven Design (DDD) in mente.
Esempi:
- DDD no-no nel mondo CouchDB (ad es. GetObjectAFor (id, ... qualche altro int, string, ObjectB, pippo) == BOOM)
- Quando DDD inizia indica che si dovrebbe utilizzare SQL invece
- considerazioni DDD per CouchDB sollevamento pesante e potenziali colli di bottiglia (vista modellazione, compattazione, replicazione, ecc)
Questo post sembrava bagnare il mio appetito (Assomiglia Il design CouchDB dovrebbe riflettere realmente l'aspetto di un'API DDD standard), ma comunque nessun dettaglio parla di considerazioni sulle prestazioni prima di percorrere questa strada. Idee? - http://www.erenaykin.net/blog/?p=21 – baseman
Non capisco davvero cosa stai chiedendo o quali sono le tue preoccupazioni. Per esempio. cosa fa "Quando DDD inizia a indicare che dovresti usare SQL invece"? Direi che DDD non dovrebbe mai dirti che dovresti usare SQL - semplicemente perché quel "SQL" non dovrebbe mai far parte del tuo dominio (a meno che tu non stia progettando un database relazionale ...). – mhanisch
Hai dato un'occhiata a questo altro post su StackOverflow: http://stackoverflow.com/questions/1530745/principles-for-modeling-couchdb-documents? Contiene alcuni buoni indicatori, non specifici per DDD ma per modellare i dati in CouchDB in generale. – mhanisch