デーブル駆動方式

union型にした個々のロジックがどうのではなく、操作という抽象に着目する

この例では、テーブルのカラムに相当するものがそれだということだろう

https://gyazo.com/eb256623a95fcca9210989790d4ce3c1

Gyazoの画像ロック.icon

扱うものが抽象になることで、コードの中で具体的な条件分岐が不要になる

テーブルの縦軸項目は可変要素です。

ビジネスの変化に応じて 支払条件は増減するでしょう。

一方、横軸項目は不変要素です。

支払条 件が増えても、単に表に行が追加されるだけで、横軸項目は変わらない 可能性が高いわけです。

問題があるとすれば、カラムの増減や、カラムが許容する値の変更に耐えられるかだったり、

カラム同士の値の制約が複雑になった時に対応しきれるか、

というのはありそう

実際、RDBのテーブルを設計しているときも、きびし〜〜〜、ってなることがある

カラムが不変、レコードが可変という風に分ける

不変をちゃんと切り出す

18章が上下のどっちにかいてるのか知らん