釣りキチプログラマー翔平の備忘録 
はじめに
現場で役立つシステム設計の原則第６章 データベースの設計とドメインオブジェクトを読んで、
今まで現場で設計をしてきた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
2022/3/22追記
現場で役立つシステム設計の原則を読んでみて、
今後現場で取り入れたいこと、気付きなどなど
まとめ記事を作ったので是非こちらも見てください！！
現場で役立つシステム設計の原則第６章を読んでの気付きなど
６章はデータベース設計における悪い設計と良い設計についてと、
ドメインオブジェクトとデータベース設計は別物として考えるべきというような内容の話が中心の章でした。
自分はデータベーススペシャリストの資格勉強を通じて
テーブル設計の視点で正規化などは完璧に理解しているつもりでした。
が、、、現場でついついやってしまう、
状態によって入ったり入らなかったりするカラムを作ったり、
テーブル設計の思想をアプリに持ち込むという点においては反省しなければと思いました。
悪いテーブル設計は取り扱う際の暗黙の知識が大量に必要
レコードの状態がステータスによって意味が変わる。
レコードが一部未知の状態(null)で登録されて後からデータが入る。
汎用的なカラムや、現時点で使っていないが後でカラム追加をしないために予備カラムを設ける。
これらは悪いテーブル設計。
こういったテーブルを扱うプログラムはテーブルを取り扱う際に大量の暗黙の知識が必要となり、
その知識は時間の経過と共に薄れて、おまじないのような処理だけが残る。
このような記載が本にありました。
今、僕が保守開発しているシステムがまさにそうなっており、
このせいでテーブル設計から読み取れない暗黙のルールをやデータの入り方のパターンを整理したり、、、
そのテーブルを取り扱う側のプログラムが複雑になってしまっています。
(最初にテーブル設計した人にこの話を聞かせたい。。。)
この本にある良い方の設計思想で作られたシステムを今までの経験でみたことがないのに、
この章に書かれている悪いテーブル設計に書かれている過去の全パターン現場で見たことがあります。。。。（笑）
いろんな意味でここは僕には印象的な箇所でした。
事実を記録するのがテーブル設計の基本
事実をinsertで記録するのがテーブル設計の基本。(過去の事実をupdateで更新したりしない)
必要に応じて、事実から導出(集計など)する必要があれば派生した２次的なテーブルを別途用意する。
事実からの導出は非同期メッセージやイベントソーシングなどが使え、
事実を記録するメインの処理とは別で切り離して考えることも可能。
(非機能要件次第なのと、導出失敗時のエラーハンドリングなど大変な面もあるが)
事実の記録＋事実からの導出で設計すると、
業務フローの途中といった状態をステップを踏んでテストデータを作る大変な作業が不要で、
事実のデータセットだけ用意して導出すれば良いので楽。
このような記載が本にありました。
事実の記録に集中してまず設計して、必要に応じて導出について考える。
このようにテーブル設計の際には２つに分けて考えると良さそうかなと思いました。
今まで、この考え方を無意識に使っていたこともあったし、
逆にごちゃ混ぜにしてしんどくなっていたこともあったので、
意識して使い分けれたら良いのかなと思いました。
ドメインオブジェクトの設計とテーブルの設計は別物
ドメインオブジェクトは業務ロジックと業務データの置き場を中心に設計し、
テーブルはデータを中心に事実をどう記録するかを中心に設計する。
そのため、ドメインオブジェクトとテーブルのカラムを機械的にマップしたり、
JPAのようにテーブルの関心事をアノテーションで
ドメインオブジェクトに入れると不要な制約が生まれる。
このような記載が本にありました。
テーブルレイアウトがそのままプログラムで取り扱うオブジェクトの単位として
テーブル操作に関する処理中心となっているシステムを今まで僕が経験した現場ではよく見かけました。
こうなると、テーブル操作を使いまわせるように設計していき、
業務の関心事とかけ離れていき、
仕様変更による影響の波及は業務的に全く関係ないところにもでたりしていました。
設計の考え方がそもそも違うということを理解した上で、
それぞれの設計を適度にすり合わせしつつ、
無理やりドメインオブジェクトとテーブルのカラムとをマップさせようとしない。
この辺りは今後の設計においてきちんと意識すべきことかなと思いました。
まとめ
現場で役立つシステム設計の原則第６章 データベースの設計とドメインオブジェクトを読んで、
この辺りは自分の経験的に重要だなと感じたので、
普段から意識して現場での作業をしていこうと思います。
- 悪いテーブル設計は取り扱う際の暗黙の知識が大量に必要
- 事実を記録するのがテーブル設計の基本
- ドメインオブジェクトの設計とテーブルの設計は別物
第３正規化について自分はデータベーススペシャリストの勉強を通じて理解したつもりでしたが、
実際にシステム開発をする際にはテーブル設計で意識することは他にもあるということに
改めて気付かされました。。。。
