データモデルを作るっていうのは、別にデータベース設計をするだけじゃなくて、アプリケーションコードの中でどんな処理フローになるかを考えて、それに適したモデルと、その引き回しの指針を決めることなんだよね
— magnoliak🍧 (@magnolia_k_) 2021年11月20日
そうしないと知らないオブジェクトがどんどん増えていく
「必要だから作った」データ構造のためのオブジェクトがそこらじゅうに溢れかえると、コードはデータ構造の詰め替えばかりになってしまう
— magnoliak🍧 (@magnolia_k_) 2021年11月20日
その場その場で最小のコード量にしようと思ってボトムアップ的に作り上げていくとそんなことが起きる
モデルを作ることで…
— magnoliak🍧 (@magnolia_k_) 2021年11月20日
1. ギョームヨーケンと実装詳細を”なるべく”引き離すことができる
2. 場当たり的なデータ構造が散らかるのを防ぐ
3. 作る過程においてギョームヨーケンへの理解が深まる
データ構造を詰め替えるためのコードが大部分を占めた時、何かがおかしいんだよね
— magnoliak🍧 (@magnolia_k_) 2021年11月20日
場当たり的なコードを書き続けると、そこら中に個別最適なデータ構造が作られてしまって、気がつくとコードの大部分がデータ構造間の形式に合わせるための詰め替えになっていたりしませんか。
コードからビジネスロジックを読み取りたい時...
- どんな入力を期待しているか
- 処理の対象・範囲は何か
- どんな条件で判断しているか
- どんな形式に変換しているか
- どんな単位で処理するか（トランザクションとか）
- データベースのカラムのうち、何を実際に使っているか
- どんな条件でデータベースを更新しているか
あたりを読み取りたいので、単なるデータ構造の変換のためのコードが増えてくると上記のようなコードが埋没して読み取りづらくなっていきませんか。
特にデータベースのカラム、不用意にお作法を守らずに参照しているコードが思ってもみなかった影響を与えることが有るので、素早く読み取りたいけど、全カラムを取得して変換して、フィルタして...みたいなコードが続くと実際に影響のあるコードを特定するのにすごく時間がかかってしまう。
ひょっとして我々が今求めているのは、そのデータがどこから来て、どこへ行くのか、出自が追跡可能なデータモデル・機能なのかもしれない(今、思い付いた)。
Rustの所有権という概念もいいけど、エンタープライズ用途だと、追跡可能性(トレーサビリティ)という概念を導入した方がいいのかもしれない。
