問題タブ [domain-driven-design]
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.
design-patterns - ドメイン駆動設計の質問
これに対する推奨される解決策をお願いしたいと思います。コンペティションのリストがあります。各コンペティションには、参加者が支払わなければならない料金が定義されています。私は 2 つの解決策を考えていますが、それはドメイン駆動設計で最も適切な解決策でなければなりません。1 つ目は、リストの代わりにコンペティションで辞書を作成することです。辞書のタイプは <Participator, bool> になります。2 つ目は、participator と feePaid の 2 つのフィールドを持つ別のクラスを作成することです。そして競争では、その新しいクラスのオブジェクトのリストがあります。
ありがとうございました
c# - 依存性注入によるリポジトリと特殊なリポジトリのデコレーターチェーン
今、私は物事をよりスマートに行う方法を見つけようとしています. そうする過程で、私ができたのは、1日でフルボトルのエクセドリンを使用することだけです.
IRepository というインターフェイスがあるとします。
そして、私は次のような実装を持っていると仮定します
さて、すべて問題ありません。リポジトリに対してすべての基本操作を実行して、すべての CRUD 機能をサポートできますが、特殊な操作が必要な場合があるため、次のようなインターフェイスがあると仮定します。
そして、そのような実装:
オーケー、これで基本的なセットアップは完了です。次に、やりたいことがもう 1 つあります。ロギングやトランザクションなどをすべて透過的にしたいと考えています。そこで、Castle Windsor や StructureMap などの依存性注入フレームワークを使用して、IRepository を要求すると、LoggingRepository と TransactionRepository によってラップされるようにします。どちらも IRepository を実装しています。
だから、私がやりたいことは次のようなものです:
Logging および Transaction デコレーターにラップされたユーザー リポジトリを返すようにしますが、これが機能する方法が思い浮かびません。これを機能させると考えることができる唯一の方法は、次のように UserRepository を実装することです。
これは、依存性注入を使用して装飾されたリポジトリを作成し、それを UserRepository のコンストラクターに渡し、それを操作を実行するリポジトリとして使用することを意味します。これは機能しますが、まだ理想的ではないと思います。
したがって、私の質問は、これがこれを行う唯一の方法であるという点で正しいのでしょうか、それともこれを正しく理解していないのか、単に何かを見逃しているだけなのかということです。また、以前にこの問題に遭遇したことがある場合、この問題をどのように解決しましたか?
asp.net - ASP.NET MVC - 複雑なオブジェクトとフォーム
次のようなドメイン オブジェクトがあるとします。
個人は、名前、電話番号、および住所が入力されるまで有効ではありません。ASP.NET MVC とフォームを使用してこれをどのように処理しますか...
個人をセッションにシリアル化し、名前の編集、電話番号の追加、住所の追加のための複数のビューを持つことができると考えていました.コントローラーアクションはセッション内の人を変更し、最終的な保存アクションはデータベースにプッシュします.
複数のビューを持ち、セッションを使用するのはあまり好きではありません。別のオプションは、保存アクションに投稿する前に、ブラウザー内で電話番号や住所を追加/削除するための要素の「動的」セクションを持つことができる単一の非常に複雑なフォームを持つことです。
複雑なオブジェクトを操作したり、フォームを介して編集したりしている人は何をしているでしょうか?
ありがとう!
domain-driven-design - ビジネス ロジックはドメインまたはサービスに配置する必要がありますか?
ドメイン エンティティ User があり、User がアイテムをショッピング カートに追加できるようにしたいとします。ここで、ショッピング カート内のアイテムが一意であることを確認したいので、User クラス内に次の関数を作成します。
これはうまくいきます。しかし、アイテムがカートに追加されるたびにユーザーに電子メールを送信したい場合はどうなるでしょうか? これを AddItemToCart に追加できますが、User クラスにある種の IEmailer 依存関係を挿入する必要があります。
別の方法として、このトランザクションを処理するサービス (ShoppingCartService など) を作成して、ビジネス ロジックを実行し、電子メールを送信することもできます。ただし、これはかなり貧弱なドメインにつながります (つまり、User クラスは getter/setter に他なりません)。
service - このエンティティリポジトリサービスの例は、ドメイン駆動設計に適合しますか?
ドメイン駆動設計で次のパターンが意味があるかどうか知りたいです。
ドメインレイヤーは、モデルとリポジトリで構成されています。アプリケーション層は、ユーザーインターフェイスから、またはModel-View-Controllerパターンのコントローラーからのクエリを処理するサービスで構成されます。
構造の詳細:
特に、メソッドをPhraseエンティティクラスに移動することは理にかなっていますか?その場合、それはどのように呼ばれますか?
編集:
上記の例は、moffdubからの回答とAdeelAnsariからのコメントの後に変更されています。変更が強調表示されます。
追加されたIPhraseRepository.GetPhrase(phraseId)と、それをどのように含めるかについてお聞きしたいのですが。
model-view-controller - MVC パターンでドメイン集約を表現するにはどうすればよいですか?
集約内のオブジェクトごとに個別のクラスを作成する必要がありますか?それとも、オブジェクトを単一の集約クラスのネストされたクラスにする必要がありますか?
asp.net-mvc - MVC と DDD を使用したブログ アーキテクチャ設計
asp.net mvc でブログ アーキテクチャを設計しています。投稿とコメントの 2 つのエンティティしかないとします。それぞれにコントローラーとリポジトリーが必要ですか? コメント付きの投稿を表示するメカニズムはどうなっていますか? ポスト コントローラはポスト リポジトリでポストを検索し、コメント コントローラにこのポストに関連するすべてのコメントを取得するように要求し、コメント コントローラから取得してビューに渡しますか? または、両方のリポジトリをクエリし、結果をビューに渡す投稿コントローラーに返すサービスを作成する必要がありますか?
domain-driven-design - リポジトリパターン:遅延読み込みの方法は?または、この集計を分割する必要がありますか?
私は、エディターとプロジェクトの概念を持つドメインモデルを持っています。
編集者は多数のプロジェクトを所有しており、プロジェクトには編集者の所有者だけでなく、多数の編集者メンバーもいます。したがって、編集者には多数の「参加」プロジェクトもあります。
私はこれをモデル化し、永続性のためにリポジトリパターンを使用するためにDDDアプローチを採用しています。しかし、私はまだパターンを十分に理解していないので、これをどのように行うべきかを判断できません。
私は、エディターとプロジェクトが潜在的に同じ集合体であり、ルートがエディターであるという前提で作業しています。したがって、エディターを取得してそのプロジェクトを列挙し、そこからプロジェクトのメンバーのエディターを列挙することができます。
ただし、リポジトリからのエディタの取得のみが許可されている場合、それを所有するエディタを取得するときに、リポジトリからすべてのプロジェクトをロードする必要があるということではありませんか?また、メンバーのエディターを遅延ロードする場合、プロジェクトにはリポジトリへの参照も必要ですか?
または、アグリゲートを分割してエディターリポジトリとプロジェクトリポジトリがある場合、新しいプロジェクトがエディターに追加されたときなど、2つの間でトランザクションをどのように処理する必要がありますか?例えば:
リポジトリパターンの意図を誤解していますか?
design-patterns - ドメイン オブジェクトにデータ アクセス層を認識させるのは正しくありませんか?
私は現在、ドメイン層からデータベースを完全に抽象化する Data Mappers を使用するアプリケーションの書き直しに取り組んでいます。ただし、 Domain オブジェクト間の関係を処理するためのより良いアプローチはどれか疑問に思っています。
- 関連するデータ マッパーから必要な find() メソッドをドメイン オブジェクト内で直接呼び出します。
- リレーションシップ ロジックをネイティブ データ マッパーに記述し (これは、例が PoEAA で行う傾向にあります)、ドメイン オブジェクト内でネイティブ データ マッパー関数を呼び出します。
「Fat Model、Skinny Controller」というマントラを維持するために、ドメインオブジェクトはデータマッパーを認識している必要があるように思えます(それが独自のものであるか、システム内の他のマッパーにアクセスできるかどうか)。 . さらに、オプション 2 は、単一のデータ マッパーに限定するのではなく、複数のデータ マッパーにまたがるテーブル アクセス ロジックを作成するため、データ アクセス レイヤーを不必要に複雑にしているようです。
では、ドメイン オブジェクトに関連するデータ マッパーを認識させ、ドメイン オブジェクトから直接データ マッパー関数を呼び出すのは正しくないのでしょうか?
更新:これらは、ドメイン オブジェクト間の関係の問題を処理するために思い描くことができる唯一の 2 つのソリューションです。より良い方法を示す例は大歓迎です。