7
Investigando un poco para obtener un proyecto CouchApp.CouchDB/NoSQL y el diseño impulsado por el dominio?
Entiendo el concepto de un Almacén de datos de documentos frente a un RDBMS normal. Y puedo captar totalmente los documentos y las vistas de modelado en lugar de usar las sentencias WHERE y JOIN. Pero no he podido encontrar muchos recursos sobre cómo modelar documentos, vistas y diseñar documentos teniendo en cuenta el Diseño Dirigido por Dominio (DDD).
Ejemplos:
- DDD no-no en el mundo. CouchDB (por ejemplo GetObjectAFor (id, ... alguna otra int, string, ObjectB, foobar) == BOOM)
- Cuando DDD comienza indica que debe utilizar SQL en lugar
- consideraciones DDD para CouchDB levantar objetos pesados y los posibles cuellos de botella (vista de la modelización, la compactación, la replicación, etc.)
Este post parecido a mojar el apetito (Parece El diseño de CouchDB realmente debería reflejar el aspecto de una API DDD estándar), pero aún así no hay detalles sobre las consideraciones de rendimiento antes de seguir esta ruta. Ideas? - http://www.erenaykin.net/blog/?p=21 – baseman
Realmente no entiendo lo que estás preguntando o cuáles son tus preocupaciones. P.ej. ¿Qué significa "Cuando DDD comienza a indicar que debería usar SQL en su lugar"? Yo diría que DDD nunca debería decirle que debe usar SQL, simplemente porque ese "SQL" nunca debería ser parte de su dominio (a menos que esté diseñando una base de datos relacional ...). – mhanisch
¿Has echado un vistazo a esta otra publicación en stackoverflow: http://stackoverflow.com/questions/1530745/principles-for-modeling-couchdb-documents? Contiene algunos buenos punteros, no específicos para DDD, sino para modelar datos en CouchDB en general. – mhanisch