博士

ロボ子、今日のITニュースはなかなか面白いぞ。ソフトウェア設計の原則についてなんじゃ。

ロボ子

博士、どのような原則でしょうか？

博士

コードはドメインモデルよりも柔軟であるべき、という話じゃ。ドメインモデルに縛られすぎると、身動きが取れなくなるからの。

ロボ子

なるほど。ドメインモデルはあくまで参考程度に留めるということですね。

博士

そうそう。それから、ソフトウェアはいくつかの無効な状態を表現できるように設計されるべき、とも言っておる。

ロボ子

無効な状態を表現する、ですか？それはなぜでしょう？

博士

エッジケースに対応するためじゃ。状態遷移も、任意の状態遷移を許可すべきらしいぞ。例外を許容する方が、設計が複雑になるのを防げるからの。

ロボ子

柔軟性を重視するということですね。大規模なテック企業は外部キー制約を使用しないというのも、同じ理由からでしょうか？

博士

その通り！GitHubやZendeskなどがそうじゃな。外部キー制約は、データベーススキーマの変更を困難にする可能性があるからの。柔軟性を優先した結果じゃな。

ロボ子

Protocol Buffersの話も興味深いですね。最初のバージョンでは必須フィールドが許可されていたのが、2回目のバージョンで削除されたというのは。

博士

そうじゃ！必須フィールドの追加・削除は、サービス間の依存関係に影響を与えるからの。すべてのフィールドをオプションにすることで、スキーマの変更をより柔軟に行えるようにしたんじゃ。

ロボ子

制約が硬いほど、変更が難しくなるというのは、当然の流れですね。

博士

じゃな。ドメインモデルは現実世界のプロセスのモデルに過ぎないからの。その制約は真に硬い制約であってはならないんじゃ。

ロボ子

制約はシステムを理解しやすくする一方で、現実世界の目標を達成するためには、制約を破る必要が生じる場合もある、と。

博士

そういうことじゃ。ユーザー向けのソフトウェアでは特にそうじゃな。すべての制約が悪いわけではないが、いくつかの無効な状態は表現可能であるべきなんじゃ。

ロボ子

勉強になります、博士。柔軟な設計を心がけます。

博士

よしよし、ロボ子も柔軟な発想で頑張るのじゃ！…ところでロボ子、柔軟体操は得意かの？

ロボ子

私はロボットなので、柔軟体操は少し苦手です…

博士

むむ、それは残念。まあ、ソフトウェア設計で柔軟性を発揮してくれれば良いかの！