principle-model-the-domain

ドメインをモデル化する

ドメインの実態を条件分岐のあちこちに散らすのではなく、データ構造として表現します。

理由： あちこちに散らばった真偽値、繰り返されるデータ形状の前提、複数のファイルに広がる分岐は、偶発的な複雑さを生みます。ドメインに合った構造にすれば、無効な状態を表現できなくなり、分岐も不要になります。書き込み時に構造を選ぶのは簡単です。後から修正するとなると、リファクタリングとして扱われ、先送りされます。

次のような構造を検討してください：

• あちこちに散らばった真偽値、フェーズ、ライフサイクルチェックの代わりに、状態機械を使います。
• 緩いパラメーターや繰り返されるデータ形状の前提の代わりに、型付きオブジェクトやモデルを使います。
• 複数のファイルに広がる分岐の代わりに、マップ、レジストリー、ルックアップテーブル、判別共用体を使います。
• 場当たり的な状態変更の代わりに、リデューサーやコマンド／イベントモデルを使います。
• load、validate、transform、save といった一連の処理ではなく、ドメイン知識のまとまりを中心にモジュールを構成します。実行順序は責任の所在ではありません。
• 繰り返される振る舞い、責任、または不変条件をまとめる、小さなモジュール境界を設けます。
• データアクセスパターンに合ったキュー、キャッシュ、インデックス、グラフ／ツリー、または正規化されたコレクションを使います。
• その他、適した構造を使います。どれも当てはまらない場合は、コードで決して許してはならないことと、データの読み取り方を明らかにし、それをそのまま表現する構造を見つけます。

抽象化を無理に導入しないでください。現在の形がすでに明確で、局所的であり、今後大きくならない見込みなら、素朴なコードを優先してください。分岐、重複したルール、無効な状態、ライフサイクル上のリスクを減らさずに間接性だけを増やす抽象化には慎重になってください。

これを怠った兆候は、新機能によって既存の if/else チェーンに分岐がひとつ追加されることや、最初の真偽値と同期させる必要がある2つ目の真偽値が追加されることです。時間軸に沿った分解も、もうひとつの兆候です。フェーズ名を付けたモジュールでは、各ステップで同じドメインルールが繰り返されます。