ドメイン駆動設計本メモ
ふじしろ教科書
ふじしろ※引用部分の太字は自分用のもの
1.2.1 ドメインモデルとは何か
たとえばペンはどのような性質を抽出すべきでしょうか。小説家に とってペンは道具で、文字が書けることこそが大事な性質です。一方、 文房具店にとってペンは商品です。文字が書けることよりも、その値段 などが重要視されます。
このことが指し示すのは、対象が同じもので あっても何に重きを置くかは異なるということです
物流システムにおいて、トラックは「荷運びできる」ことを表現すればそれで十分です。「エンジンキーを回すとエンジンがかかる」といったことまで表現する必要はありません。
こういった事象、あるいは概念を抽象化する作業がモデリングと呼ばれます。その結果として得られる結果がモデルです。
ドメイン駆動設計では、ドメインの概念をモデリングして得られたモデルをドメインモデルと呼びます。
ふじしろ3.2.1 可変である
値オブジェクトは不変の性質が存在するため交換(代入)によって変更を表現していましたが、エンティティは交換により変更を行いませ ん。
エンティティの属性を変化させたいときには、そのふるまいを通じて属性を変更することになります
エンティティと値オブジェクトの違いを述べた部分。
人が改名する時、その人が新しい人に置き換わるわけではない。
置き換わるのは名前で、本人の同一性は保たれる。
この時、実装的には、人エンティティに改名メソッドを持たせる感じになる
ふじしろ仕様（Specification）
オブジェクトの評価のみを行うドメインオブジェクト。
例えば、何かしらの集合を表現するドメイン（Circleとか）があったとき、集合の最大数を決めておきたいようなパターンで、
それをドメイン本人に評価させようとするとドメインがリポジトリに接続することになる。
そういった問題を避けるため、そのドメイン専用の仕様を評価するような処理を書くのが仕様オブジェクト。
補足
Q:仕様オブジェクトの理解として、上記の文章から抜けていると思われる内容を補足せよ
A:仕様オブジェクト（Specification Object）についての説明は、基本的な概念を捉えていますが、いくつかの重要な側面が補足されていません。以下にその内容を補足します：
-
再利用性と組み合わせの容易さ：
仕様オブジェクトは再利用可能であるべきです。同じ仕様を異なるコンテキストで再利用できるように設計されていることが多いです。また、複数の仕様を組み合わせて新しい仕様を簡単に形成できるように、論理演算（AND, OR, NOTなど）をサポートすることが一般的です。 -
ドメインの知識のカプセル化：
仕様オブジェクトは、ドメインに関する特定のルールや条件をカプセル化することで、ドメインオブジェクト自体の複雑さを減らします。これは、ビジネスルールが変更される際に、ドメインオブジェクトのコードを変更する必要がないことを意味します。 -
テストの容易さ：
仕様オブジェクトを使用すると、ビジネスルールが単独でテストしやすくなります。これは、ビジネスロジックの一部を分離してテストすることを可能にするため、ソフトウェアの品質保証に貢献します。 -
拡張性：
仕様オブジェクトはシステムの拡張性を高めます。新しいビジネスルールや仕様が必要になった場合、既存のドメインオブジェクトに影響を与えることなく、新しい仕様オブジェクトを追加することができます。
これらの側面は、仕様オブジェクトが設計パターンとしてどのように役立つかを理解する上で重要です。特に、ソフトウェアアーキテクチャにおける柔軟性、拡張性、再利用性を高めるための重要な手段となります。
ふじしろファーストクラスコレクション
Listなどの集合オブジェクトをラップした独自集合クラスを作成し、コレクションを操作するようなメソッドをもたせたもの。
GPTの補足
仕様はドメインでありながらデータの入出力（リポジトリとの接続）を行うことがある。
ドメインとしてはそのような入出力は避けたいという考えもあり、その場合に活用される。
ファーストクラスコレクション（First Class Collection）は、オブジェクト指向プログラミングにおける設計原則の一つで、コレクションをラップする専用のクラスを作成し、そのクラスにコレクションに関連する振る舞いやロジックを集中させるアプローチを指します。この設計原則の主な特徴と利点は以下の通りです：
-
コレクション操作のカプセル化：
ファーストクラスコレクションは、コレクションに対する操作（追加、削除、検索など）を専用のクラス内にカプセル化します。これにより、コレクションに対する操作が一箇所に集中され、コードの可読性と保守性が向上します。 -
ビジネスルールの明確化：
コレクションに対するビジネスルールや制約（例えば、リスト内の要素の最大数など）をこのクラス内で定義し、適用します。これにより、ビジネスルールが分散せずに一元管理されるため、ルールの変更や拡張が容易になります。 -
再利用性と拡張性：
コレクションに特有の操作やルールを持つクラスを作成することで、そのクラスをシステムの他の部分で再利用しやすくなります。また、新しい機能やルールを追加する際にも、既存のコードに影響を与えることなく拡張が可能です。 -
エラーの低減：
コレクションに関する操作が一箇所に集中するため、エラーが発生しにくくなります。例えば、不正な要素の追加を防ぐロジックを、コレクションを使用する各場所で個別に実装する代わりに、ファーストクラスコレクション内で一度だけ実装することができます。
このように、ファーストクラスコレクションはコレクションデータの扱いをより安全で、管理しやすく、柔軟にするための効果的な手段となります。
ふじしろ仕様とファーストクラスコレクションの対比
ファーストクラスコレクション（First Class Collection）と仕様オブジェクト（Specification Object）は、どちらもオブジェクト指向プログラミングにおいて設計の洗練を助ける概念ですが、彼らの焦点と用途は異なります。以下に、両者の主な特徴と対比を示します：
ファーストクラスコレクション
-
主な目的：
コレクションデータを管理するための専用クラスを提供し、コレクションに対する操作とビジネスロジックをカプセル化します。 -
利点：
- コレクション操作の集中化
- ビジネスルールの一元管理
- エラーの可能性低減
- 再利用性と拡張性の向上
-
適用例：
リスト、セット、マップなどのコレクションに対する共通の操作やビジネスルールを管理する際に適用します。
仕様オブジェクト
-
主な目的：
ビジネスルールや条件を評価するためのオブジェクトを提供し、ドメインオブジェクトの状態が特定の基準を満たしているかを判断します。 -
利点：
- ビジネスルールのカプセル化
- ドメインオブジェクトの複雑さの低減
- ビジネスルールの再利用性とテストの容易さ
- 拡張性の向上
-
適用例：
ドメインオブジェクトが特定の条件を満たすかどうかを判断する際に適用します。
対比と評価
-
焦点の違い：
ファーストクラスコレクションはデータ構造（特にコレクション）の管理に焦点を当てているのに対し、仕様オブジェクトはビジネスルールとその評価に焦点を当てています。 -
再利用性：
両方の概念は再利用性の向上に寄与しますが、ファーストクラスコレクションはデータ操作の再利用に、仕様オブジェクトはビジネスロジックの再利用に重点を置いています。 -
設計の清潔さ：
どちらのアプローチも、コードの可読性と保守性を向上させ、設計をより清潔に保つのに役立ちます。 -
適用の文脈：
ファーストクラスコレクションは主にデータコレクションを扱う際に有用であり、仕様オブジェクトはビジネスルールの複雑な評価が必要な場合に特に役立ちます。
総じて、ファーストクラスコレクションと仕様オブジェクトは異なる問題領域に対処しますが、どちらもオブジェクト指向設計をより柔軟で保守しやすいものにするための重要なツールです。