DDD - ファクトリを実装する方法

ドメイン駆動型設計でファクトリを実装する方法を知りたいと思います。（例）DDD - ファクトリを実装する方法

どこの工場のインターフェイスと実装を配置する必要がありますか？工場が作成するドメインオブジェクトのインタフェースを作成する必要はありますか？私はリポジトリ、サービス、...のための工場を作る必要がありますか？

私はどのようにそれらを工場と一緒に置くことができますか？

ありがとうございました。

2013-03-08 user2149358

imhoこの問題は、DDDの工場についての話は、一般的な工場についての話と比べてかなり制限されているため、誤って閉じられています。典型的には3つのアプローチがあります。すなわち、別々のファクトリで、リポジトリを工場にしたり、ドメインエンティティを単に新しいものにしたりするためです。 – jgauffin

しかし、ドメインエンティティに関する質問は一般的には混同しないでください。質問があいまいになるからです。それを具体的にするか、複数の質問を作成してください。 – jgauffin

工場は単純なクラスで、通常は静的である必要があります。また、作成するエンティティまたは値オブジェクトに対して静的メソッドとして実装することもできます。ファクトリは、ドメインオブジェクトを直接作成し、ドメインオブジェクトのみを作成する必要があります。さらに、ドメインオブジェクトには依存関係が注入されてはならないため、工場は依存関係注入に縛られるべきではありません。

ドメインオブジェクトはインターフェイスを実装すべきではありません。これは不必要な抽象化です。

一方、サービスとリポジトリの実装は依存関係があり、DIコンテナによって作成される必要があります。

出典

2013-03-08 17:45:01 eulerfx

使い捨てプロトタイプを開発するために単独で作業している（進化が期待されておらず、テストもない）場合、インターフェイスは実際には不必要な抽象化です。異なるレイヤーで作業する大規模なチームを持つ複雑なドメインでは、インターフェイスにより、ドメイン変更後のリファクタリングの効果的な並列化が可能になります。さらに、インターフェースがなければ、適切なユニットテストがはるかに難しくなります。 –

特にドメインオブジェクトの場合、インタフェースは不必要な抽象化であるだけでなく、有害な抽象化でもあります。一方、サービスやリポジトリのインタフェースは確かに価値があります。しかし、単なるテストのためのインターフェイスの宣言は、素晴らしいmockingフレームワークで避けることができます。一般的に、私は抽象化のコストを強調したいだけです。まず、抽象化の価値、次にコストを学びます。 – eulerfx

私は、ほとんどの場合、典型的なドメインオブジェクトはあなたが言及したもの以外のインターフェースを必要としないことに同意するでしょう。しかし、いつものようにそれはドメインに依存しています:)あなたのドメインで相互交換できる一般的なオブジェクト（戦略）がある場合、それは有用であり、必要でさえあります。しかし、私はそれが例外であると思う。 –

DDD - ファクトリを実装する方法

答えて

関連する問題