エンジニアとしての強み
各カテゴリの詳細を確認できます
モデリング
ドメインとプログラムの間で全単射の関係を構築するためのモデリング手法について紹介します。
全単射
モデリングしたい対象と、プログラムの間で全単射の関係になるようにする
人工的なルールを少なくする（プログラム上のルール⇒対象を単射に）
プログラムの為に人工的なルールを追加すると、対象の変化量とは別の変化に対する悩みがエンジニアには生じてしまいます。
例：オブジェクトに不必要にIDを付与しない
- IDを付与しPKとすることでRDBのテーブル作成要件を満たすことができ、一意条件はUQとしても設定できるが、他テーブルではそれは明示的ではない
- 例：そのようなオブジェクト間に中間テーブルを設けた際、元のドメインの情報について明示されるべき関係が中間テーブルには明示されない
- IDを設けた場合、多くの場合その生成方法も議論する必要が生じる(連番なのかuuidなのかcuidなのか)
- IDを設けた場合、ビジネスロジックやフロントエンドもIDの処理で汚染されてしまう
- 本来の一意キーで検索する場合が多く、そのキーカラムの順序構造を保っていないIDを使用した場合、検索性能の向上の為に不自然な最適化を誘発してしまう可能性がある
- 本来備わっている一意キーを見落とし、ドメインではあり得ない重複を生じさせる可能性がある
注意点
特にRESTful APIの文脈やORMの制約でIDを付けてしまうことがありますが、RESTful APIの要求はリソースが永続的に特定可能なことであり、IDと同義ではありません。
解決策：
- リソースを特定する不変の要素が他にないか探す
- 複合キーをPKとしたくない場合は、その文字列結合などを用いる
ドメイン上必要なルールを十分に整理する（プログラム上のルール⇒対象を全射に）
開発に要する時間を短縮するためには、ドメイン上のルールを十分に整理することが重要です。プログラムを正しく制御するためにはモデリング対象に応じた処理が必要になります。
十分でないとプログラムが正しく動かず開発が難航し、機能ごとに都度追加をしていくことでドメインルールが散在する保守性の低いプログラムとなることで技術的な負債に満ちたアプリケーションが出来上がります。
解決策：
予めドメインのルールとしてどのようなものがあるか整理する
モデリング≠オブジェクト設計
モデリングはどのようなオブジェクトが存在し、どのようなフィールドがあり、オブジェクト間にどのような関連があるのか、というERD作成と同一視されることがあります。
しかし、例えば物理的な世界をモデリングする際、特定の物体（と幾何学的束縛条件）のみを抽出しても十分でなはなく、その物体に作用する自然法則やあり得る変化（時間は進んでも戻ることはない）もまたモデリングする必要があります。
同様に、ドメイン駆動設計においても特定のオブジェクトに起きうることやオブジェクトに作用する自然法則もまたモデリングされなくてはなりません。
問題点
ルールがあちらこちらで重複してモデリングされると、開発に時間を要します。遅かれ早かれ自然法則をモデリングする必要が出てきますが、これが各機能開発の場面である場合、本来は共通不変の自然法則であったはずがそれぞれの機能で重複して開発され、あるいは不完全な自然法則を生成してしまいます。
解決策：
- 不完全なオブジェクトを生成しない：対象ではありえないフィールド状態でオブジェクトインスタンスを生成しない（空のコンストラクタ、アトミックでないフィールドの書き換え（あるフィールドに相関して別のフィールドも同時に変えるべき場合、これをカプセル化する）等を避ける）
- オブジェクトのメソッドとして設定できないものもドメインルールに含める：ドメインルールは何らかのオブジェクトのメソッドである必要はない（寧ろ無暗に帰属させようとすると、不必要な結合を生んでしまう）
設計思想カテゴリ
他のカテゴリを見る