私はドメイン駆動型設計の初心者です。現在私はそれらの間に階層を持つ約5豆を持っています。厳密に言えば、豆はDTOです。しかし、私はそれらをドメイン層からサービス層とコントローラに返すでしょう。これは私のためにうまくいきましたが、ドメイン駆動設計では、ドメイン層はBOを返さなければならず、サービスはコントローラがDTOにマップするDTOまたはBOを返す必要があります。最終的には、サービスが返すオブジェクトをJSON（データのみ）に変換するので、私はこの点を見ません。ですから、私はBOとDTOを別々にする必要があります。DDDのエンティティとDTOは常に必須です
私は、特定のビジネス機能に対してすべての操作を実行し、必要に応じて複数のDTOを返すステートレスビジネスオブジェクトを持っていることに注意してください。私が正しい道を歩いていれば、助言してください。
私は別個のBOとDTOを持っているのは本当に必然です。
必要ですか？いいえ、DDDの警察はあなたのドアをノックすることはありません。
しかし、の関心事の分離は、それらが異なる扱いを受けるべきであることを示しています。
ビジネスオブジェクトはモデルの一部です。モデル内のデータがビジネス不変量を満たすことを保証する責任があります。
DTO（またはより正確に - あなたの表現）はAPIの一部です。他のアプリケーションと共有できる言語に依存しないメッセージです。
ここで重要なアイデアは、ビジネスオブジェクトがモデルの一部であるため、ビジネスのニーズを満たすためにビジネスオブジェクトを積極的に変更することをサポートすることです。しかし、ビジネスモデルを最適化するたびにクライアントコードを書き直す必要がないように、安定性が必要なAPIの場合はそうではありません。
もう1つの見解は、ビジネスオブジェクトがそれを実施するために使用される信頼境界を越えて表現が期待されるということです。アンドレアス・ハルベルクこの(slides)
に良い話を持っている。しかし、この場合、私はあなたがanemic domain modelの罠に落ちているようにこれはたくさんの音がないロジック
でビジネスオブジェクトを持つ参照してください。あなたの資料をもう一度見直すことをお勧めします。あなたのモデルでデータベースに話しているエンティティが多すぎると懸念があるなら、あなたはどこかでプロットを失ってしまいます。ドメインモデルはデータベースと全く話しません。
私が知る限り、ドメイン層はデータベース呼び出しを必要としないがアプリケーション層で起こりうるすべての操作を持つべきであると理解しています。私の現在のアプリケーションでは、ビジネスルールはほとんどなく、検証もほとんどありません。このアプリケーションは、タスクのキューを維持し、タスクが完了した後にタスクのデータを更新するアプリケーションの多くです。データが提出されてもそれが有効な場合、いくつかのバリデーションがあります。 – prashant
この場合、ドメインオブジェクトに検証を追加することになり、すべてのDB呼び出しはサービスから行われ、ドメインのオブジェクトはサービスで作成されてデータの整合性が確保されます。しかし、まだ1つの質問が残っています。私はjson/xml形式ですべてのデータを送信する予定です。この場合、私はDTOが必要ですか、または単にDomainオブジェクトをjson/xmlに変換できますか？パーサーはビジネスロジックの方法を無視し、ゲッターにのみ集中してDTOを作成します。このアプローチはいいですか？ – prashant
あなたはエンティティまたはDTOを削除しますか？ – guillaume31
エンティティを削除します – prashant
エンティティのないDDDは理にかなっていません。それを読んで（理想的には本の1つです）、その理由を理解するでしょう。 – guillaume31