私は DDD の初心者で、アーキテクチャに関する小さな問題に直面しています。
私たちのシステムは、ビジネス データをさまざまな形式 (Excel、Word、PDF、その他の特殊な形式) でエクスポートできる必要があります。
ソースデータを取得し、それらをターゲット形式でエクスポートし、最終結果をユーザーに準備するという全体的なプロセスを担当する必要があるレイヤーはどれですか? ドメインとアプリケーションの責任を混同しています。
また、エクスポート サブシステムに関して、実装とその共通インターフェイス コントラクトはインフラストラクチャ レイヤーに属すべきですか?
アプリケーション層もドメイン層も他の「層」もありません。DDDは階層化アーキテクチャではありません。このテーマに関するmorのタマネギアーキテクチャまたはポートとアダプタパターンを検索します。
今、あなたの問題の核心に。あなたが直面している問題は、別の制限されたコンテキストであり、システムの別のコンポーネントに行く必要があります。それをレポーティングと呼びましょう。また、これは単なるプレゼンテーションの問題であるため、ドメインロジックはありません。DDDはそれに適していません。いくつかのSQLビューを作成し、NHibernate、LINQ2SQL、EF、またはプレーンなDataReaderを使用してそれらを読み取り、Builderパターンを使用してWordなどのドキュメントを作成するだけです。アグリゲート、リポジトリ、サービス、またはその他のDDDビルディングブロックはありません。
もう少し進んで、アプリケーション内のすべてのデータ表示を別のコンポーネントで処理できるようにすることをお勧めします。それがCQRSです。
私は通常、可能な場合は単純なアプローチを取ります。
ドメイン コードは、ドメインの言語 (名詞、動詞など) を実装します。
アプリケーション コードは、この言語を使用して詩を作成します。
したがって、あなたの例では、出力の構築はアプリケーションの問題ですが、アプリケーションが話すビットの構築は(言及していないため)ドメインの問題になります。
たとえば、レポートが販売データで構成されている場合、日付、請求書、注文などはドメインで抽象的に構築され、アプリケーションはこれらを使用してドキュメントを作成することに関係します。