データモデリングとドメイン駆動設計
渡辺幸三氏のデータモデル大全を読みました。
業務システムを扱うエンジニアであれば必読と言える書なのでぜひ読んでみてください。
ドメイン駆動設計に関する課題感
さて、これを読みながらここ数年ドメイン駆動設計に感じていた課題を言語化してみました。
それは、「ドメイン駆動設計で語られるモデリングの領域がプログラミングに関するものに限定されすぎている」という点です。
これは「データの入出力[1]はドメインの主要な関心事ではない」というような主張にみられます。
確かにデータの入出力に関心を払わなければプログラミングに関心事を集中できます。
しかし、それはデータモデル大全の中で指摘しているようなプロセス中心のあり方という指摘そのものだと感じました。
コアドメインに集中する
エリック・エヴァンスのドメイン駆動設計の中では「コアドメイン」に集中することの重要さを説いています。
確かに、事業にとって事業価値の源泉となるコアドメインに集中することは理にかなっています。
また、一番複雑で、かつ事業の変化を受けやすい部分になることが多いのもコアドメインです。
変更しやすいコアドメインが価値をあげるのはエンジニアの肌感にも合います。
システムの大部分は「データの入出力」
一方で、システムを構成する大部分は「データの入出力」でできています。
「データの入出力」がうまく出来ていないとコアドメインだけがうまくいってもシステム全体を見たときに価値を上げているとはいえません。
事業のコアドメインでない、比較的コモディティ化した部分を設計することはまさにデータモデリングが得意とするところです。
この比較的コモディティ化しているという特性もやっかいで、コモディティ化しているがゆえにユースケースの分析では出てこないが、事業を運営する上では当たり前に必要であったりします。
これこそまさにデータモデル大全で言われるように様々なデータモデルを経験値としてエンジニアが蓄え、当たり前にシステムに組み込めるようになることが必要です。
また、コアドメインの部分も「特注」ではなく、できるだけ早い段階で標準化し、データモデルに組み込むことはスケールを考える上では価値のあることです。
違った見方をすれば、データモデリングに精通したエンジニアになればこの「特注」の部分を抑え、初期の段階からスケールするシステムを開発できる可能性があります。
ドメイン駆動設計の中でのデータモデリング
ドメイン駆動設計は間違いなく価値があります。それと同様にデータモデリングにも価値があります。
また、書籍でもドメイン駆動設計の中でデータモデリングをしなくていいと主張している訳でもありません。
ただし、データモデリングに関する言及もありません。
このデータモデリングに関する言及がないのが課題で、ドメイン駆動設計でコアドメインに集中するためにもデータモデリングは十分すぎるほど重要です。
データモデル大全での指摘
データモデル大全の中ではドメイン駆動設計は批判的な見方をされています。
データモデルがしっかりとすれば、あとはノーコードツールで画面を提供してシステムは完成できるという筆者の主張は一定理解できます。
私としては、そうではない事業のコアドメインを抱えるシステムの中で、それではうまくいかないケースもあるように感じます。
最終的には、システム・サービスの扱う内容や、チームのエンジニアの特性をみて選択していくことになるのだろうと思っています。
まとめ
プログラミングはその汎用性の高さから、まだ不確実なもの、未確定なものを柔軟にシステムとして組み上げることが出来ます。
関数従属性を主とするデータモデルはその理論的に守られた構造から、出来ること、出来ないことを構造的に表すことが出来ます。
プログラミングは柔軟に変更出来ますが、変更にはエンジニアの手が入ります。
データモデルは一度データが登録されると構造を簡単には変更できませんが、予め組み込まれた範囲の変更はエンジニアの手を介さず、ユーザーのデータ登録でシステムの挙動を変えることが出来ます。
システム・サービスに「質」的な価値を提供するのがコアドメインに注力するドメイン駆動設計だとすると、「量」的な価値をもたらすのはデータモデリングになります。
どちらかの思想に偏るのではなく、両方のいいとろこを学び、質・量ともに価値の高いシステムが作れるようになることが重要です。
以上が、渡辺幸三さんのシステムデータ大全を読みながらつらつらと思ったことです。
データモデリングとドメイン駆動設計の間でもんもんとしている人に何らかの気づきになれば幸いです。
-
データの入出力とは画面の入出力やDBへの保存、抽出のことを指しています。 ↩︎
Discussion