principle-model-the-domain

ドメインをモデル化する

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

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

• あちこちに散在するブール値、フェーズ、ライフサイクルのチェックの代わりに、状態機械を使います。
• まとまりのないパラメーターや繰り返される形状の前提の代わりに、型付きモデルを使います。
• ファイルに分散した分岐の代わりに、マップ、レジストリ、ルックアップテーブル、判別可能なユニオンを使います。
• その場しのぎの状態変更の代わりに、リデューサーやコマンド／イベントモデルを使います。
• 読み込み、検証、変換、保存といった一連の流れではなく、ドメイン知識のまとまりを中心にモジュールを構成します。実行順序は責務の所在を示すものではありません。
• 繰り返される振る舞い、責務、または不変条件をまとめる、小さなモジュール境界を設けます。
• アクセスパターンに応じて、キュー、キャッシュ、インデックス、グラフ、ツリー、正規化されたコレクションを使います。
• その他、適合する構造を使います。適合するものがない場合は、コードが決して許してはならないことと、データの読み取られ方を明らかにしてから、それをそのままエンコードする構造を見つけます。

ドメインで使われる言葉を使ってください。 型、関数、モジュールには、ドメインで使われる言葉を名前として付けます。名前を付ける前に、CONTEXT.md やプロジェクトのドキュメントにある用語集など、最も近い用語集を読み、その用語を使います。用語集で避けるよう指定されている言葉は決して使わないでください。操作には、それを実行する仕組みではなく、ドメインにおける効果に基づいた名前を付けます。

抽象化を無理に押し付けないでください。現在の形が明確で、局所的であり、拡張される可能性も低いなら、単純なコードを優先します。分岐、重複したルール、無効な状態、ライフサイクル上のリスクを減らさずに間接性だけを増やす抽象化には、懐疑的でいてください。

これを見落とした兆候は、新機能によって既存の if/else チェーンに分岐が一つ追加されることや、互いに同期し続けなければならないブール値がもう一つ増えることです。時間軸に沿った分解も兆候の一つです。フェーズ名を付けたモジュールでは、同じドメインルールが各ステップで繰り返されます。

レビュー時。 他の人の変更をレビューする場合は、次の3点も確認してください。

• 1つの概念には1つの名前。 コードですでに名前が付いている概念に、新しい名前を付けていないか指摘します。修正の方針は、コードで使われている言葉をそのまま使うことです。
• コンテキストを分ける。 コードベースの異なる部分では、同じ言葉が別々の概念を指すことがあります。それらを、意味ごとにオプションのフィールドを持つ1つの型にまとめる変更があれば指摘します。修正の方針は、IDのように両方で同じ意味を持つものだけを共有し、それぞれの部分に別の型を用意することです。統合の対象は1つの概念であり、1つの言葉ではありません。
• 共有コードはすべての呼び出し元に影響する。 変更が加わる共有関数、型、定数それぞれの呼び出し元を列挙します。ある依頼のために行った変更が、別の業務機能を担う呼び出し元の振る舞いを変える場合は指摘します。修正の方針は、共有部分を分岐させ、依頼元の経路だけを変更することです。異なる業務機能がそれぞれ変更する、似ているだけのコードは別々の判断です。統合を求めないでください。