私はこれに慣れていないので、私の理解はまだ不安定です。
プロジェクトにPersonモデルとAccountTypeモデルがあります。各人はアカウントタイプを参照します。
私の理解が正しければ、Personは間違いなく集約ルートですが、AccountTypeはおそらくアカウントタイプテーブルのエントリがほとんど静的であり、Personの外部では意味がないため、そうではありません。
ただし、新しい人を作成するときはアカウントタイプを設定する必要があるため、ユーザーに割り当てるアカウントタイプにアクセスするにはリポジトリが必要なようですが、私が持っているリポジトリコードでは、集約ルートにしかアクセスできません。
これを構造化する正しい方法は何でしょうか？
AccountTypeこれは、集約ルートから参照されるもう1つの集約ルートだと思いますPerson。多くの単純な集合ルートを持つことは絶対に正常です。VaughnVernonの記事を参照してください。パート1、pを参照してください。5：
[Qi4j]を使用した金融デリバティブセクターの1つのプロジェクトで、Niclas [Hedhman]は、彼のチームが、いくつかの値型プロパティを含むルートエンティティだけですべての集計の約70％を設計できたと報告しました。残りの30％には、合計2〜3個のエンティティがありました。これは、すべてのドメインモデルが70/30に分割されることを示すものではありません。これは、集約の高い割合が単一のエンティティであるルートに制限される可能性があることを示しています。
あなたの質問では、それは完全には理解されていません。リポジトリにアクセスして集約ルートのプロパティを初期化する際の問題は何ですか。
ただし、新しい人を作成するときはアカウントタイプを設定する必要があるため、ユーザーに割り当てるアカウントタイプにアクセスするにはリポジトリが必要なようですが、私が持っているリポジトリコードでは、集約ルートにしかアクセスできません。
Personクラスの初期化は。で処理する必要がありますPersonFactory。
これPersonFactoryはサービスであるためAccountTypeRepository、適切なインスタンスを見つけてAccountType、そのタイプの完全に構築されたPersonインスタンスを返すための参照を持つことができます。
更新：また、IDでAccountTypeを参照することも同様に機能するというメモを追加したいと思います。WPFやSpringMVCなどの豊富なデータバインディング機能を備えたGUIフレームワークを使用して、このプロパティに直接アクセスできる場合は、参照に直接アクセスする方が便利な場合があります（もちろん、表示のみで、変更はできません）。ビューに表示します。idアプローチを使用している場合、これにより、単純なエンティティに対してもViewModels（FormBeans）を作成しなければならない場合があります。
AccountTypeはそれよりも複雑で、知識レベルに属していると思います（質問の説明を参照してください）。
集計と値オブジェクトの選択に戻ると（これも参照）、情報システムの抽象化レベルと構成機能によって異なります。クラスの観点からはAccount、値オブジェクトのように見える場合がありAccountType、相互に置き換えることができます。これは、Color値オブジェクトを切り替えるのと同じですが、知識レベルの観点からは、ユーザーは動作をカスタマイズする必要があります。選択したAccountTypeのシステムの例。たとえば、特定の「プレミアム」アカウントの割引を変更します。したがって、知識レベルがある場合はAccountType、別のリポジトリを作成するためのIDを持つものになります。
最も重要なことは（AccountTypeにIDを持つエンティティがあり、単純な列挙型ではないと仮定する）...
アカウントタイプと個人は、IDでのみ相互に参照する必要があります。