問題タブ [rich-domain-model]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
2477 参照

c# - 単体テストのリッチ ドメイン モデル

これは貧血ドメイン モデルでした。

そして、これはその動作です:

そして、それはかなりテスト可能です:

ただし、データと動作がより論理的にまとまるリッチ ドメイン モデルを実践したかったのです。したがって、上記のコードは次のように変換されます。

ただし、テストの問題が発生します。

単体テスト エラー:

モックされたオブジェクトからメソッドを直接呼び出すと、モックされたオブジェクトは、そのプロパティまたはメソッドのいずれかが呼び出されたかどうかを検出できません。リッチ ドメイン モデルを単体テストする適切な方法は何ですか?

0 投票する
10 に答える
50369 参照

domain-model - リッチ vs 貧血ドメイン モデル

Anemic Domain Model よりも Rich Domain Model を使用する必要があるかどうかを判断し、2 つの良い例を探しています。

私は、サービス --> リポジトリ --> ストレージ層システムに裏打ちされた貧血ドメイン モデルを使用して Web アプリケーションを構築し、BL 検証にFluentValidationを使用し、すべての BL をサービス層に配置しています。

Eric Evan の DDD 本を読んだことがありますが、彼は (Fowler などと同様に) Anemic Domain Models はアンチパターンであると考えているようです。

だから私は本当にこの問題についていくつかの洞察を得たいと思っていました.

また、Rich Domain Model の良い (基本的な) 例と、それが提供する Anemic Domain Model に対する利点を本当に探しています。

0 投票する
1 に答える
66 参照

oop - ドメイン駆動設計でDBからのデータを必要とするビジネスロジックを設定する方法

私はDDDを学ぼうとしていますので、ご容赦ください。Issue という集計があるとします。StatusId プロパティがあります。このステータスは次のようになります。オープン、クローズド...ステータスと呼ばれるデータベーステーブルに保存されます。(これは、特定のユーザーが特定のステータスを持つことができるため、ユーザーが新しいステータスを追加できるようにするためです) ここで、Issue 集計で次のようなメソッドを作成しました: public static void SubmitIssue(Guid projectId, string issueTitle, string description ...)

このメソッドは、req で新しい Issue を作成します。params その後、正しい状態に設定する必要があります。ただし、状態はDBで指定されています。データベースアクセスをまったく実行してはならないビジネスロジックを実行するときにDBからデータを取得する必要がある場合、このシナリオをどのように処理しますか? 助けてください

0 投票する
2 に答える
2320 参照

domain-driven-design - ドメイン駆動設計: 多くのデータ フィールドを持つ複雑なモデルをどのように扱うか?

データ フィールドとビジネス ロジックの両方を含む豊富なドメイン モデルを使用して、アプリケーションにドメイン駆動設計の原則を適用しようとしています。私は多くの DDD の本を読みましたが、それらのドメイン モデル (エンティティと呼ばれる) は非常に単純なようです。以下のような 10 ~ 15 個のデータ フィールドを持つドメイン モデルがある場合に問題になります。

ご覧のとおり、このドメイン モデルには多くのデータ フィールドが含まれており、それらはすべて重要であり、取り除くことはできません。優れたリッチ ドメイン モデルにはセッター メソッドを含めるべきではなく、そのデータをコンストラクターに渡し、ビジネス ロジックを使用して状態を変更する必要があることを私は知っています。ただし、上記のドメイン モデルの場合、コンストラクター メソッドで 15 以上のパラメーターが発生するため、すべてをコンストラクターに渡すことはできません。メソッドには 6 ~ 7 個を超えるパラメーターを含めるべきではありません。

では、大量のデータ フィールドを持つドメイン モデルを処理するにはどうすればよいでしょうか? 分解してみるかな。もしそうなら、どのように?あるいは、ビルダー クラスまたはリフレクションを使用して、インスタンス化時にそのプロパティを初期化し、コンストラクターを多くの引数で汚染しないようにする必要がありますか? 誰でもアドバイスできますか?ありがとう。

0 投票する
1 に答える
84 参照

c# - Unity Of Work + 豊富なドメイン

Unit of Work を使用してリッチ モデルを実装しようとしています。

ビルドは正常に実行されますが、このクラスでは作業単位が null です。

私はこのクラスへのインターフェースを持っています。

そして UnityConfig.cs で、型を登録します

Unit Of Work が初期化されないのはなぜですか? どうすれば解決できますか?

0 投票する
1 に答える
66 参照

javascript - リッチ ドメイン モデルとフォーム マッピング

TLDR: リッチ ドメイン モデルと「重い」セッターを単純な HTML フォーム マッピングと組み合わせる方法は?

あるプロパティのセッターが他のプロパティを変更すると問題が発生します (直接またはセッターを使用して - これは問題ではありません)。

よりよく説明するためのサンプルクラス(PHPでは、これは問題ではありません-私は思います):

}

このサンプルのアイデアは、(製品の購入/作成の) コストと獲得したい利益を設定できるということです。次に、(製品を販売するための) 価格が計算されます。また、価格を変更することもできます-その後、利益が計算されます。(コストを変更すると、価格ではなく利益が変更される可能性がありますが、問題には関係ありません)。

例えば:

多くの理由 (つまり、コマンド ライン フロントエンドと CRON ジョブ) により、「バックエンド」コードにリッチ オブジェクトが必要です。

HTML フロントエンドでは、コスト、利益、価格に対応する 3 つの入力を含むフォームを取得します。ユーザーが値を変更してフォームを送信すると、セッターの順序が問題になり、混乱する可能性があります。例えば:

  • ユーザーは製品ボタンをクリックして編集します
  • 次の値を持つフォームを見る: cost=100、profit=10、price=110
  • 利益を 20 に変更します
  • フォームを送信

問題は、バックエンド マッパーが POST フォームから値を取得し、setCost(100)、setProfit(20)、次に setPrice(110) を呼び出すことです。これは、120 に変更する必要がある古い価格であるため、不適切です (ユーザーは 20 を希望していました)。利益と 100 コスト)。

私が見る唯一の解決策は、すべてのドメイン モデル ロジックをフロントエンド (JavaScript) にも実装することです。そのため、コスト/利益入力を変更すると、価格入力の値が変更されます。次に、すべての入力に正しい値があり、POST されたデータは「オーバーライド」の問題なしに配置できます。このサンプルでは簡単ですが、多くのフィールドがある場合 (2 つの異なる言語で同じコードを記述すると時間がかかり、エラーが発生しやすくなります)、またはそれらの間のロジックが非常に複雑な場合 (すべてが JS で簡単に実装できるわけではありません) の場合は不可能です。

これを解決する方法はありますか?:)

PS: 一時的なプロパティと遅延評価 (つまり、コストと価格のみがプロパティであり、編集可能であり、利益は常に計算されます) を使用することはできません。私は両方の方法から変更することができなければなりません。また、一部の重い計算には不便です。すべての小道具が存在し、データベースに保存する必要があります。

0 投票する
2 に答える
947 参照

c# - 豊富なドメイン モデルと依存関係を理解する

私は、豊富なドメイン モデルと、ドメイン エンティティがセマンティック動作の実装を提供するオブジェクトに密接に結合されていないドメイン エンティティにセマンティック機能を組み込む方法について頭を悩ませようとしています。

たとえば、Userエンティティをドメイン モデルに組み込みたいが、その実装を ID フレームワークによって駆動したい

これで、ビジネス ルールに従って動作し、永続性と実装を意識しないドメイン モデルができました。

しかし、依存関係がなく、 と に結合されていない場合、どのように正確に機能し、機能するはずですDisableUser()か?AddToRole()UserManagerRoleManager

  • 一般的に、何が欠けていますか?
  • ドメイン エンティティは、動作を提供するオブジェクトに依存する必要がありますか?
  • ドメイン モデルを実装プロバイダーから切り離すにはどうすればよいですか?
0 投票する
0 に答える
105 参照

c# - Entity Framework - ドメイン モデルとは異なる永続モデル

次の遅延コードがあります。Pesistence Model と (貧血) Domain Model の間には分離があります。この分離と暗黙の変換の利点は何ですか? 欠点はありますか?

私は、暗黙的な変換で以下が可能であることを知っています: SplitAmountEF saEF = dbContext.SplitAmount.Find(id); SplitAmount sa = saEF; //暗黙の変換。交換して使用できます。

ドメイン モデルが永続モデルとほぼ同じである場合は、(ドメイン モデルをまったく使用せずに) 永続モデルのみを使用した方がよいのではないでしょうか。

例: