2017-04-14 13 views
1

私はDDDを学び始めました。だから私は愚かな質問のために謝罪します...複雑な値オブジェクトを作成するにはどうすればいいですか?

私はPostエンティティを持っています。それはうまく見えます。ただし、tagsが必要です。エンティティとして意味を成されていない

class Post 
    attr_reader :tags 
    attr_reader :title 
    attr_reader :text 
    # ... 
end 

class Tag 
    attr_reader :name 
    attr_reader :description 
    # ... 
end 

タグ: のコードでは、この(Rubyコード)のように見えます。私はtag自体は必要ありません。 しかし投稿用リポジトリを実装するにはどうすればよいですか? 私は2つの亜種を見つけました:

1. ビルドタグは同じリポジトリにあります。このように:

# PostRepository 
def find(id) 
    # getting post data from storage here 
    # getting tags data 
    Post.new(title, text, tags_data.map { |tag_data| Tag.new(tag_data[:name], tag_data[:description])) 
end 

しかし、それは醜いです。理由を明確に言うことができません。

タグ用に別のリポジトリを作成します。

# PostRepository 
def find(id) 
    # getting post data from storage here 
    Post.new(title, text, tag_repository.find(tag_ids)) # or tag_names or tag_something 
end 

よく見えます。しかし、値オブジェクトのための別のリポジトリを作るのはいいですか?

DDDの正しい方法は何ですか?

UPD: 一方、利用可能なタグをすべて取得する必要があります。そして、投稿でタグを変更する必要はありません。タグの名前は同一性のように見えます。多分私は根本的に間違っていますか?多分タグは実体ですか?

UPD2:

この問題は、私のデザインのスキルは非常に貧弱であることを私に示しています。 そのため、私の中に2つの質問があります。 これらは次のとおりです。

  1. エンティティのリポジトリ内に値オブジェクトを作成する正しい方法は何ですか。
  2. 私の問題で値とエンティティの違いを確認する方法。結局のところ明らかに見えます。 指定された条件に従って、タグは値です。 Postのリポジトリによって構築されていることは大丈夫です。

しかし、この条件は、貧弱な分析の結果です。私がもっと見ることができるなら、私はそのタグがそれ自身のライフサイクルであることを知るでしょう。ポストの文脈では、タグは不変です。

+0

タグが 'ddd'と呼ばれていて、それを' domain-driven-design'に名前を変更して、以前にタグ付けされた投稿に反映されているかどうかを確認してください。それ以外の場合は値です。それ以外の場合は、投稿のコンテキストでは不変のエンティティですが、タグ管理のコンテキストでは変更可能なエンティティです。 – plalx

+0

@plalx、回答にあなたのコメントを移動できますか?それは有用で、私はそれを投票したい。 – anoam

答えて

2

タグはほとんどの場合、ドメイン内の通常の値オブジェクトです。タグは、独自のライフサイクルを持っていれば、エンティティになる可能性があります。率直に言えば、あなたのドメインではそうではないと思います。それぞれのタグを同じプロパティを持つ別のコピーに置き換えることができます。

クエリタグにメソッドを追加して、ドメインリポジトリに追加することができます。 DDD集約ルールの違反ではありません。集約は実際には一貫性に関するものです。集約コンテキストの外側でそれらを変更できる場合、リポジトリは集約の一部を返すべきではありません。ただし、集計の値オブジェクトを読み込み専用に明示的に返すことができます(たとえば、選択した日付範囲内のすべての投稿のすべてのタグを収集するなど)。それに加えて、クエリメソッドは、効率のためにリポジトリ内に配置する必要があります。つまり、おそらく最良の解決策は、CQRSの原則に従って別々の読み取りモデル(たとえばnosql dbを使用)を使用することです。このようにして、クエリのニーズに合わせてモデルを明示的に調整することができ、非常に効率的です。

関連する問題