ドメイン駆動設計について少し読んでみると、集約ルートからのトラバーサルによって集約内のすべてのエンティティにアクセスすることになっているようです。
ただし、同時に、プロパティ/フィールドが保護または非公開になるように、データを実際にカプセル化する必要があります。
したがって、私の質問は次のとおりです。フィールドが保護/非公開の場合、集計をどのようにトラバースすることになっていますか?
現時点で設定した方法は次のとおりです。ドメインモデルのすべてのプロパティを内部としてマークし、「設定」のメソッドを保護としてマークします。このように、少なくともモデルの外部からプロパティにアクセスすることはできませんが、モデル内のオブジェクトは他のオブジェクトのプロパティにアクセスでき、オブジェクト自体からのプロパティの設定のみを許可します。
私がこれを行ったとしても、これは他の集約エンティティのプロパティにのみ適用されるべきであるように感じます (つまり、顧客の「名前」は非公開のままですが、顧客の「注文」は内部としてマークする必要があります。 Customer -> Orders -> などからのトラバーサル)
これに関するガイダンスはありますか？
編集：
質問のより具体的な例を挙げてみましょう。オブジェクト グラフには、Bookshelf と Book という 2 つのオブジェクトがあります。この例では、Bookshelf が集約ルートであり、Books が Bookshelf に格納されているため、集約内のエンティティであるとします (Bookshelf には書籍のコレクションがあります)。
本棚に新しい本を追加するメソッドを書きたいと思います。DDD のベスト プラクティスに従って、Bookshelf クラスに AddBook(Book book) などのメソッドを記述する必要があると思います。
ただし、同じタイトルの本を本棚に追加できないというビジネス要件がある場合はどうなるでしょうか。Bookshelf.AddBook メソッド内に、書籍のコレクションをチェックして、この書籍がまだ存在していないことを確認するロジックが必要です。
問題は、Book オブジェクトを適切にカプセル化された方法で作成し、その "Name" プロパティにパブリックにアクセスできないため、それができないことです。
これはかなり不自然な例であることは理解していますが、問題をよりよく示していることを願っています。また、これは単なる DDD の問題ではなく、実際には OO カプセル化の問題であることにも気付きました。私がやろうとしていることを解決するための非常に一般的で簡単な方法があるに違いないと確信していますが、私はそれを非常に考えすぎています。