ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita

この記事のモチベーション RDB(Relational DataBase)の歴史は長く、ノウハウも蓄積されている。 関係代数という学問もあるなどアカデミックにも研究されており、 国家資格である「データベーススペシャリスト」も、ほとんどこのRDBのことを扱うなど、 RDBは一定の体系が確立した技術と言える。 一方で、2010年ごろより広まったNoSQL、特にドキュメント指向DBに関しては、 当然ながらRDBに比べると未成熟な段階であろう。 また主観だが、NoSQLは、スケーラビリティといった物理的側面にfocusが当たることが多かったのではと思う。 一方で、論理的側面 = モデリング に関して、および物理的側面と論理的側面のトレードオフの関係について、 議論されつくされているとは言えない。 本稿では、DDD(ドメイン駆動設計)というプログラミングの論理的側面の手法を、 各DBがいかに扱えるか

[efcl]

ドキュメント指向DBとDDD

[yojik]

本題とは外れるけど「検査結果」を集約ルート「ユーザ」の配下にするモデリングは自分なら絶対しないけど（詳しくはアナパタ参照）、そうなりがちなのがDDDの嫌なところ。集約ルート有害論です。