設計の堅さ

設計の堅さ

私は設計するとき、「堅く作る」ことを意識することが多いです。

堅く作るほど将来の拡張に強くなる、と経験的に感じているからです。

ただし、何でもかんでも堅くすればよいわけではありません。

今回は、設計における「堅さ」について整理してみます。

なぜ堅くすると拡張に強いのか

私がここで言う「堅くする」とは、例えば次のようなことです。

いずれも「制約」を設ける行為です。

私は「現時点で不要なものは許可しない」という感覚で、必要最小限の制約を置くようにしています。

では、なぜそれが拡張に強さを生むのか。

理由は、変更の影響範囲を小さくできるからです。

拡張では、機能追加や修正が発生します。 そのとき影響範囲が見えていれば、変更はそれほど怖くありません。

一方、ひとつの変更で無関係に見える箇所まで壊れることもあります。 これは、影響範囲が把握できていない状態です。

私が挙げた制約は、いずれも影響範囲を狭める方向に働きます。

影響範囲を小さくすることが、拡張に強い設計の重要な要素だと考えています。

堅さの違い

私は以前、「テーブル定義は堅く作るべきだ」と強く考えていました。

それは、先に述べたように拡張に強くするためです。

一方で、UIに引きずられてDB設計が決まっていく状況には違和感がありました。

例えば、UIは比較的変更しやすい層です。 WebでもCLIでもデスクトップアプリでも、一般に上位レイヤーの変更は下位レイヤーより容易です。

上位レイヤーに依存する箇所は少ない一方で、下位レイヤーは多くの上位レイヤーから依存されています。 そのため、下位レイヤーを変えると上位レイヤー側の修正も必要になりがちです。

もちろんレイヤー分離が適切なら影響は最小化できますが、構造的に下位レイヤーの方が依存される箇所は多く、変更影響は大きくなりやすいと言えます。

DBのテーブル定義は、一般に下位レイヤーに位置します。

UIに引きずられてDBテーブル定義を決めるのは、上位レイヤーの都合を下位レイヤーに持ち込みすぎているように感じました。

つまり、テーブル定義の堅さとUIの堅さは、同じものではないのではないかという違和感です。

何が混ざっていたのか

この違和感を考えていくと、「堅さ」には2つの側面があると気づきました。

それは、

です。

テーブルが担うべきなのは「意味の堅さ」です。

これは、アプリケーションのルールそのものと言ってよいでしょう。

一方でUIが担うのは「形の堅さ」です。

この2つを同じ「堅さ」として扱っていたことが、混乱の原因だったのだと思います。

引きずられていたのは“意味”ではなかった

UI変更に引きずられてDBテーブル定義が変わるとき、実際には“意味”が変わっているわけではないことが多いと感じました。

変わっているのは、見せ方や操作の流れです。ドメインとしての意味まで変わっているわけではありません。

それなのにテーブル定義まで変わってしまうのは、設計として望ましくありません。 これは、UIの“形”をDBテーブル定義に適用しすぎているためです。

これは一見シンプルに見えますが、層の責務を混ぜることになり、将来的な拡張性を損なう可能性があります。

テーブルを堅く作ること自体は間違いではありません。むしろ重要です。

大切なのは、堅くする対象が“意味”であり、“形”ではないという点です。

意味が堅ければ、UIは安心して柔らかくすることができます。

なぜなら、意味の整合性が下位レイヤーで保証されるからです。

変更容易性を担保したい上位レイヤーにとって、下位レイヤーで整合性が保証されることは大きな強みです。 長期的には、プロダクトの底力にもつながると感じます。

最後に

今回は、設計の堅さについて整理しました。

私は堅さの側面を混同していたため、整理するまでに時間がかかりました。 ただ、責務の観点で捉えるとすっきり理解できます。

「DBに期待される責務は何か」という観点で考えると、堅くすべきなのは必ずしも「形」ではないと分かってきます。

何を堅くするべきかを見直す、よい機会になりました。

UIモデルと永続モデルは一致しなくてよい。むしろ一致させない方がよい場面は多いと感じます。

この気づきは小さいようでいて、設計全体を変えるきっかけになります。

堅さは将来の拡張性を支える重要な考え方ですが、使い方を誤ると足かせにもなります。 その前提を忘れず、何を堅くするのかを意識して設計していきたいと思います。

Share: X (Twitter)