principle-model-the-domain

ドメインをモデル化する

ドメインの実態を条件分岐に散在させるのではなく、データ構造にエンコードします。ドメインに合った構造にすると、無効な状態を表現できなくなり、分岐もなくなります。書き込み時に構造を選ぶのは簡単です。後から修正するとなるとリファクタリングのように感じられ、先送りされます。

次のような方法を検討してください。

• 散在するブール値、フェーズ、ライフサイクルチェックの代わりに、ステートマシンを使います。
• 緩やかなパラメーターや繰り返される形状の前提の代わりに、型付きモデルを使います。
• 複数のファイルに分散した分岐の代わりに、マップ、レジストリ、ルックアップテーブル、または判別可能なユニオンを使います。
• その場しのぎの状態変更の代わりに、リデューサーまたはコマンド／イベントモデルを使います。
• load、validate、transform、save のような手順ではなく、ドメイン知識のまとまりを軸にモジュールを構成します。実行順序は責務の所在ではありません。
• 繰り返される振る舞い、責務、または不変条件をまとめる、小さなモジュール境界を設けます。
• アクセスパターンに応じて、キュー、キャッシュ、インデックス、グラフ、ツリー、または正規化されたコレクションを使います。
• ほかにも、適合する構造を使います。適合するものがない場合は、コードで絶対に許してはならないことと、データの読み取られ方を整理し、それらを正確に表現する構造を見つけます。

抽象化を無理に導入しないでください。現在の形がすでに明快で、局所的に完結しており、今後大きくなる可能性も低いなら、退屈なコードを選んでください。分岐、重複したルール、無効な状態、ライフサイクル上のリスクを減らさずに間接性を増やす抽象化には、懐疑的であるべきです。

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