7
Faire des recherches pour accélérer la mise en œuvre d'un projet CouchApp. Je comprends le concept d'un magasin de données de document par rapport à un SGBDR régulier. Et je peux totalement saisir des documents et des vues de modélisation au lieu d'utiliser les instructions WHERE et JOIN. Mais je n'ai pas été en mesure de trouver de nombreuses ressources sur la façon de modéliser des documents, des vues et des documents de conception avec Domain Driven Design (DDD) à l'esprit.CouchDB/NoSQL et la conception de domaine?
Exemples:
- DDD non-non dans le monde CouchDB (par exemple. GetObjectAFor (id, ... un autre int, string, ObjectB, foobar) == BOOM)
- Lorsque DDD commence indiquant que vous devez utiliser SQL au lieu
- considérations DDD pour soulever des charges lourdes CouchDB et goulots d'étranglement potentiels (vue modélisation, le compactage, la réplication, etc.)
Ce poste semblait mouiller mon appétit (On dirait que Le design de CouchDB devrait vraiment refléter ce à quoi ressemble une API DDD standard), mais toujours aucun détail ne parle de considérations de performance avant de s'engager dans cette voie. Des idées? - http://www.erenaykin.net/blog/?p=21 – baseman
Je ne comprends pas vraiment ce que vous demandez ou quelles sont vos préoccupations. Par exemple. que fait "Quand DDD commence à indiquer que vous devriez utiliser SQL à la place"? Je dirais que DDD ne devrait jamais vous dire que vous devriez utiliser SQL - simplement parce que ce "SQL" ne devrait jamais faire partie de votre domaine (sauf si vous concevez une base de données relationnelle ...). – mhanisch
Avez-vous jeté un oeil à cet autre post sur stackoverflow: http://stackoverflow.com/questions/1530745/principles-for-modeling-couchdb-documents? Contient de bons pointeurs, non spécifiques à DDD mais à des données de modélisation dans CouchDB en général. – mhanisch