ここまでデータモデリングにおけるいくつかの手法を見てきました。
データモデリング手法 | イミュータブルデータモデル | ミュータブルデータモデル |
---|---|---|
副作用があるか | ある(command) | ない(query) |
対象領域 | 狭い(専門的なデータモデル) | 広い(汎用的なデータモデル) |
実際にソフトウェアを構築する際にはこれらをそれぞれ選択しなければいけません。
問題なのは、一度データを保存してしまうと中々捨てられない、ということです。
継続的デリバリーのソフトウェア工学では「学びの最適化」と「複雑さ管理の最適化」がソフトウェアエンジニアの仕事だ、と言っています。
これは、シンプルなデータ構造を小さく作り徐々に増やしていくというインクリメンタルなアプローチのほうが学びや複雑さの管理を最適化させやすい、ということを指しています。
これを達成するために以下の組み合わせを推奨しています。
データモデリング手法 | イミュータブルデータモデル | ミュータブルデータモデル |
---|---|---|
副作用があるか | ある(command) | ない(query) |
対象領域 | 狭い(専門的なデータモデル) | 広い(汎用的なデータモデル) |
データモデリング手法にはイミュータブルデータモデルを選択しています。
これはデータ構造をシンプルにし、データを全て保存するという目的を達成するためです。
副作用がある処理を選択しているのは、新しいソフトウェアを作る時はほとんどの場合新しいデータが必要になるからです。
部分的に副作用がない処理(query)を作ることはありますが、それをはじめから作ろうとすると小さくはじめられない、という問題が発生してしまいます。
そのため、複雑な検索処理のようなものは後から付け足していきます。
専門的なデータモデルを選択しているのは、はじめから汎用的なデータモデルを作ろうとすると大きく失敗してしまうからです。
小さくはじめて小さく失敗するために対象領域を狭くしています。
いくつかの学びを得た後に、ミュータブルデータモデル、query、汎用的なデータモデルを採用していくことで複雑な検索処理に対応していきます。
データモデリング手法 | イミュータブルデータモデル | ミュータブルデータモデル |
---|---|---|
副作用があるか | ある(command) | ない(query) |
対象領域 | 狭い(専門的なデータモデル) | 広い(汎用的なデータモデル) |
このふたつの設計思想を混ぜないことで、よりシンプルにデータを扱うことができるようになります。