26

運用型/トランザクション型のアプリケーションで作業している場合、DDD は自然なことであることがわかりました。しかし、私は常に、報告タイプの機能を処理する合理的な方法で立ち往生しています。

私が話しているレポートは、レポートの生成だけでなく、比較的複雑なクエリを実行する関数にもバインドされています。(トレーダーが行ったすべての注文の概要を表示したり、特定の株を持つ取引口座の口座概要を表示したりするなど)。それらは、それらの操作機能と一緒に使用される単純なクエリまたはサポート機能である可能性があります。

そのような関数の場合、SQL (または任意のクエリ言語) で結合を実行し、関心のある列を取得し、マッサージされた結果セットを返すことができれば、非常に自然です。ただし、DDD ではうまくいかないようです。追加の特別なリポジトリが必要であるか、既存の最も関連性の高いリポジトリが特別な「エンティティ/値オブジェクト」(特殊化された結果セット) を返す必要があります。この種の特別な「エンティティ」には、実際にはドメインの意味はありません。

意味のあるドメイン層を利用したい場合、異なるリポジトリから多くの余分なルックアップが作成される可能性があり、さらにドメインまたはサービス層で多くの集約作業が発生する可能性があり、パフォーマンスが大幅に低下する可能性があります。

また、これらの種類の関数に別の「パス」を用意することも考えました。これは、「DDD パス」を経由せず、DB からレポート データを取得する独自の方法を持ち、表示用の結果を構成します。ただし、アプリケーションが不必要に複雑になるだけでなく、さらに悪いことに、従来の DB 指向の開発に慣れている開発者が適切でなくてもこのパスを使用する傾向があるように、追加のパスを提供しました。

このような状況は非常によくあることだと思いました (通常、大きなシステムには運用機能だけでなく、レポート機能や照会機能も含まれません)。人々がどのように対処しているか知りたいですか?

4

4 に答える 4

24

DDD レポーティングに関しては、ほとんどの場合、別個の境界コンテキストとサポート サブドメインがあり、ドメイン駆動型の設計はやり過ぎです。DDD の最も重要な概念を思い出してください。つまり、モデリング作業をコア ドメインに集中させ、それ以外は可能な限り単純なソリューションを使用して実装します。

于 2012-07-19T16:47:42.330 に答える
1

One approach would be to have a separate reporting system which ran data feeds from your app's data store to store another copy of the data in a more relational format.

A shortcut I've used is to create a view or stored procedure to return the joined data into a simple dumb object.

于 2012-07-19T05:08:59.237 に答える
1

比較的複雑なクエリ。(トレーダーが行ったすべての注文の概要を表示したり、特定の株を持つ取引口座の口座概要を表示したりするなど)

リポジトリがこのようなタスクを実行するのは一般的です。これをいかに効率よく実装するか、お悩みかと思いますが、その答えが「遅延読み込み」です。

たとえば、「トレーダーが行ったすべての注文の要約」を見てみましょう。「まとめ」は報告作業なので、それは脇に置きましょう。ドメイン タスクは、「トレーダーのすべての注文を見つける」ことです。次のようなリポジトリ メソッドがあるかもしれません。

List<Order> findOrdersByTrader(Trader trader);

これは、注文ごとに最低限の (要約) 情報のみをロードすることで実装できます。その後、リポジトリ インターフェイスをエンティティに挿入するOrderと、エンティティ自体がリポジトリを呼び出して、必要に応じて追加のサブエンティティを読み込むことができます。

更新：あなたのコメントは問題をより明確にします - 私は以前に集計部分を誤解していました。その場合、「注文概要」は本当にあなたのドメインに属しているようです。概念がドメインの一部であることが明らかでない場合もありますが、それがユーザーが話している機能 (「このトレーダーが出した注文の概要を表示したい」) であり、これを実行できる既存のオブジェクトがない場合です。 、それはあなたのドメインに隠された概念の兆候です。結局のところ、 「各株の注文数」を追跡するオブジェクトが必要であり、このオブジェクトをドメインの一部にできない理由はありません。

于 2012-07-19T09:01:38.250 に答える