1

C# レイヤード アプリケーションを設計していますが、ドメイン オブジェクトがリポジトリと ServiceLayer について認識できるかどうかを知りたいです。

そうでない場合 - Article.CalculatePrice() や Offer.CalculatePrice などの複雑な関数を解決するにはどうすればよいですか。

私はEF5を使用しています。

更新: 私のシナリオは次のとおりです: 想像を絶するルールとある種の奇妙な価格計算シナリオに従わないレガシー DB の上にこれを構築する必要があります。

たとえば、私は を持っていますがArticle A { Type: Curtain, Color: Blue, Dimension: 200cm }、DB に特定の価格が定義された記事はありません -> そのため、PriceGroups どの価格設定ルールが適用されるかを調べる必要があります。

たとえば、記事に適用される次のグループが存在する可能性があります。

 - Article A { Type: Curtain, Color: Blue, Dimension: 200cm } <-- does not exist
 - PriceGroup { Type: Curtain, Color: Blue, Dimension: NULL, Price: -5 EUR (*relative* price) }
 - PriceGroup { Type: Curtain, Color: NULL, Dimension 200cm, Price 25 EUR (*absolute* price) }

つまり、PriceGroup と Article はどのような方法でも集約できず、価格グループは階層的に整列していませんが、仕様によって適用されます。

だから：私見 ArticlePriceService は PriceGroups について知る必要があるため、 ArticlePrice が見つからない場合は、グループから計算された Price を返す必要があります。したがって、このすべてをドメイン オブジェクトに入れると、ArticleDO は ArticlePriceService について知る必要があり、ArticleDO は PriceGroupService について知る必要があります。

この問題を解決する方法が本当に混乱しています。例または私を提供してみてください..

4

1 に答える 1

1

IMHOはすべてのアイテムを繰り返し処理し、Item.GetPrice()を要約する必要があります。

個別に取得するためにリポジトリが必要Itemsな場合は、適切に定義された集計がないように思えます。理想的には、ArticleおよびOffer集計はすでにこの情報を持っていて、外部データなしで計算できる必要があります。

一部の外部データ (おそらく VAT 率など) の要件がある場合、この種の動作はDomain Serviceにカプセル化する必要があります。この場合、おそらくArticlePriceCalculatorサービスOfferPriceCalculatorです。

更新 従来のデータベースがドメインに流れ込んでいるようです。これは避けなければならないことです。ユビキタス言語に関してドメインを「純粋」に保ち、データベースの性質がドメイン モデルの設計にまったく影響を与えないようにします。ビジネス上の問題(データベースの問題ではない)を表現する慎重に設計されたドメイン モデルがあれば、データベースからモデルにデータを取得する最善の方法を考えることができます。古いデータベースがあることを考えると、腐敗防止レイヤーを強くお勧めします. このレイヤーは、美しいドメインと醜いデータベースの間に障壁を提供するように設計されています. ドメイン モデルの設計が損なわれないように、データベース スキーマの癖や偏心はここで処理する必要があります。

于 2013-06-17T09:33:52.193 に答える