タグ付けされた質問 「domain-driven-design」

ドメイン駆動設計（DDD）は、実装を進化するモデルに接続することにより、複雑なニーズに対応するソフトウェアを開発するためのアプローチです。

4
ドメイン駆動設計とクロスドメイン相互作用
私は比較的DDDの初心者ですが、知識を沸騰させて蒸留するために手に入れることができるあらゆるものを読んでいます。 私はこのDDDの質問に出くわし、その答えの1つに興味をそそられました。 DDDバウンドコンテキストとドメイン？ 回答の1つで、ポスターは、製品が少なくとも2つのドメインにあるeコマースシステムの例を示しています。 1）製品カタログ2）在庫管理 わかりました。つまり、eコマースのフロントエンドでは、商品情報の表示に関心があり、在庫管理には関心がありません。 だが。Webページに在庫レベルを表示したり、在庫のエディション番号を表示したりすることができます（在庫が本、雑誌などであるとします）。この情報は、インベントリドメインから取得されます。 それで、これをどのように処理しますか？あなたは a）製品ドメインと在庫ドメインの両方の集合体をロードしますか？b）在庫数と在庫数の製品ドメインエンティティの一部のプロパティを保持し、在庫エンティティが更新されたときにドメインイベントを使用してこれらを更新しますか？ 最後の質問です。私たちはドメインの永続性を忘れ/無視し、ドメインについて考えることを意図していることを知っています。しかし、これをよく考えてみると、上の例では、製品カタログと製品在庫用に2つのDBテーブルが存在する可能性があります。これらは同じ製品なので、同じ識別子を使用しますか？または、データに1つのテーブルと1つのテーブル行を使用して、関連するデータを集計プロパティに単純にマップできますか？
2
DDD-多数の子を持つ集合ルート
私はこの質問の前置きとして、私はDDDに比較的慣れていないので、ここでいくつかの根本的な間違いを犯しているかもしれないと言います。 私は、（財務的な意味で）アカウントとトランザクションの概念を含むプロジェクトに取り組んでいます。アカウントはそれに対して入力された多くのトランザクションを持つことができます。 アカウントとトランザクションは両方ともエンティティであり、アカウントはトランザクションを含む集約ルートであるように見えます。これは、トランザクションがアカウントなしでは存在できないためです。 しかし、これをコードに適用するようになると、すぐに問題が発生しました。多くの場合、アカウントのすべてのトランザクションのリストを常に保持しておくことは、特に役に立ちません。アカウントの残高を計算したり、与信限度などの不変条件を適用したりできることに興味がありますが、トランザクションのサブセットを簡単に操作できるようにしたい（たとえば、日付範囲内のトランザクションを表示したい）。 後者の場合、私が使用していた場合、TransactionRepositoryリスト全体（場合によっては非常に大きい）をロードすることなく、必要なオブジェクトだけに効率的にアクセスできます。ただし、これにより、アカウント以外のものをトランザクションで使用できるようになります。つまり、アカウントの概念を集約ルートとして破っています。 このような状況に人々はどのように対処しますか？集約ルートに対して潜在的に膨大な数の子をロードすることによるメモリとパフォーマンスへの影響を受け入れますか？
2
リポジトリへまたはリポジトリへ
ドメインドリブンデザインについて初めて知ったとき、データベースに対する穴居人のようなSQLクエリを投げたクールな子供たちにとって、かつては一流であるように思われるリポジトリと作業単位パターンも紹介されました。EFやNHibernateのようなORMは、作業単位とリポジトリの両方を1つのAPI（セッションまたはコンテキストと呼ばれる）に実装するため、そのトピックを深く掘り下げれば読むほど、それらは必要なくなったように見えます。 今、私は何をすべきかわかりません。リポジトリするかしないか。このようなリークの多い抽象化は複雑すぎてデータアクセスを簡略化するものは一切追加しないという主張を本当に理解していますが、アプリケーションのあらゆる側面をEntity Frameworkなどに結合するのは適切ではないと感じます。通常、私はいくつかの簡単なガイドラインに従います： ドメイン層は、エンティティ、サービス、リポジトリを含むシステムの中心です... インフラストラクチャ層は、ファイル、データベース、プロトコルなどのインフラストラクチャ関連のドメインインターフェイスの実装を提供します。 アプリケーション層は、物事を結び付け、すべてをオーケストレーションするコンポジションルートをホストします。 私の解決策は通常次のようになります： Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. 私は、IRepository<'T>データへのアクセス方法を教えてくれる他のものに依存しないドメインの問題でもあるを使用して、ドメインレイヤーをクリーンに保ちます。IModule2Serviceデータアクセスを必要とする具体的な実装を行うときは、注入DbContextし、これによってインフラストラクチャレイヤーに直接結合する必要があります。（Visual Studioプロジェクトに入ると、循環依存関係のために、これは本当にトリッキーになる可能性があります！） さらに、作品の保管庫やファックトンの代わりになるものは何ですか？CQRS？純粋なインフラストラクチャフレームワークを抽象化するにはどうすればよいですか？
1
ORM POCOはドメインエンティティを置き換えますか？
これは、この質問にいくぶん似ていますが、より広義です。 一般的には、EF 4.1のようなオームズはPOCOSをサポートし、それは今あなたのドメインエンティティを持ってしても意味がないことがデータベースに永続化されたオブジェクト？ EF 4やLinq-to-SQLなどの古いORMでは、「データベースオブジェクト」が自動生成され、データベースに密結合されていたため、重要なアプリケーションの場合、より堅牢でインテリジェントなドメインエンティティにマッピングされていました。就職。 新しいORMを使用して堅牢なドメインエンティティを構築し、そのドメインエンティティとDBMSの間のマッピングを提供するだけのデータレイヤーを作成するという考えはありますか？ 書面では、これが常に目標であると感じていますが、少なくとも.NETの世界では、利用可能なツールを使用して（簡単に）簡単に実現することはできません。
5
DDD集計ルートを見つける
みんなのお気に入りのゲームをプレイして、Aggregrate Rootを見つけましょう。正規のCustomer / Order / OrderLines / Product problemドメインを使用してみましょう。従来、Customer、order、productはARであり、OrderLineはOrderの下のエンティティです。この背後にあるロジックは、顧客、注文、および製品を識別する必要があるが、OrderLineは注文なしには存在しないということです。したがって、私たちの問題領域では、顧客は一度に1つの未配達注文しか持てないというビジネスルールがあります。 これにより、注文は顧客の集計ルートの下に移動しますか？そうだと思います。しかし、そうすることで、顧客のARがかなり大きくなり、後で同時実行の問題が発生しやすくなります。 または、顧客が特定の製品をその生涯に1回しか注文できないというビジネスルールがある場合はどうでしょうか。これは、顧客が注文を所有することを要求するより多くの証拠です。 しかし、配送に関しては、顧客ではなく注文に対してすべてのアクションを実行します。個々の注文を配送済みとしてマークするために顧客全体をロードする必要があるのは、一種の愚かです。 これは私が提案しているものです： class Customer { public Guid Id {get;set;} public string Name { get; set; } public Address Address { get; set; } public IEnumerable<Order> Orders { get; set; } public void PlaceOrder(ThingsInTheOrder thingsInTheOrder) { // Make sure there …
1
クライアントは集約ルート以外のエンティティのメソッドを呼び出すことができますか？
エバンスは、彼の本「ドメイン駆動設計」の第6章「集合体」で、集合体の概念を紹介しています。彼はさらに、その概念を実装に変換するためのルールを定義しています（Evans 2009、pp。128-129）： ルートENTITYは内部ENTITIESへの参照を他のオブジェクトに渡すことができますが、それらのオブジェクトは一時的にしか使用できず、参照を保持できない場合があります。 他のルールについて詳しく説明した後、彼はそれらをこの段落に要約します。 エンティティと値オブジェクトを集合体にクラスター化し、それぞれの周りに境界を定義します。各Aggregateのルートになるエンティティを1つ選択し、ルートを介して境界内のオブジェクトへのすべてのアクセスを制御します。外部オブジェクトがルートへの参照のみを保持できるようにします。内部メンバーへの一時的な参照は、単一の操作内でのみ使用するために渡すことができます。ルートはアクセスを制御するため、内部構造の変更によって盲目的に対処することはできません。この配置により、Aggregate内のオブジェクトおよびすべての状態変化におけるAggregate全体に対してすべての不変式を適用することが現実的になります。 では、一時的な使用とは正確にはどういう意味ですか？ 私の同僚は、集約ルートのみがクライアントのパブリックインターフェイスを公開していることを理解しています。クライアントは、集約ルート以外のエンティティで操作を呼び出す機会がありません。 引用された文に対する私の理解は異なります。実際、クライアントが内部エンティティの操作を呼び出すことを明示的に許可していることを理解しています。しかし、それらをルートから取得した後にのみ。 具体的な例を見てみましょう： Cart多くので構成されているとしましょうItems。それぞれにItemがありQuantityます。モデルはユースケース「1つの特定のアイテムの数量を増やす」をサポートする必要があります。アイテムの外部に影響を与える不変式に違反することはできません。 クライアントが呼び出しによってこれを実行できる場合、cart.item(itemId).increaseQuantity()またはクライアントに呼び出しのみを許可する必要がある場合、モデルは上記のルールに違反していcart.increaseItemQuantity(itemId)ますか？後者の利点は何でしょうか？
3
CQRS / ESでは、コマンドは別のコマンドを作成できますか？
CQRS / ESでは、コマンドはクライアントからサーバーに送信され、適切なコマンドハンドラーにルーティングされます。そのコマンドハンドラーは、リポジトリーからアグリゲートをロードし、その上のいくつかのメソッドを呼び出して、それをリポジトリーに保存します。イベントが生成されます。イベントハンドラー/佐賀/プロセスマネージャーは、コマンドを発行するためにこれらのイベントをリッスンできます。 そのため、コマンド（入力）はイベント（出力）を生成し、それがシステムにさらにコマンド（入力）をフィードバックできます。さて、コマンドがイベントを発行せず、別のコマンドをエンキューするのが一般的な方法でしょうか？このようなアプローチは、外部プロセスでの実行を強制するために使用できます。 編集： 私が考えている特定のユースケースは、支払いの詳細の処理です。クライアントはPayInvoiceコマンドを送信します。そのペイロードにはユーザーのクレジットカードの詳細が含まれます。PayInvoiceHandler通過MakeInvoicePayment支払いゲートウェイとの相互作用の原因である別のプロセスにコマンドを。支払いが成功すると、InvoicePaidイベントが生成されます。PayInvoiceコマンドが保持された後、コマンドが保持される前に何らかの理由でシステムがクラッシュした場合MakeInvoicePaymentは、これを手動で追跡できます（支払いは行われません）。MakeInvoicePaymentコマンドが持続した後、システムがクラッシュする前にInvoicePaidイベントが持続する場合、ユーザーのクレジットカードに請求が行われているのに、請求書に支払い済みのフラグが付けられていない可能性があります。その場合、状況を手動で調査し、請求書に手動で支払い済みのマークを付ける必要があります。
1
DDDのいくつかの概念を実際のコードに適用する方法は？内部の特定の質問
私はDDDを研究しており、現在、実際のコードに概念を適用する方法を見つけるのに苦労しています。私はN層で約10年の経験があるので、私が苦労している理由は、私のメンタルモデルがそのデザインにあまりにも結合しているためです。 私はAsp.NET Webアプリケーションを作成し、単純なドメインであるWeb監視アプリケーションから始めています。要件： ユーザーは、監視する新しいWebアプリを登録できる必要があります。Webアプリにはわかりやすい名前が付けられ、URLをポイントします。 Webアプリは定期的にステータス（オンライン/オフライン）をポーリングします。 Webアプリは定期的に現在のバージョンをポーリングします（Webアプリには、特定のマークアップでシステムバージョンを宣言するファイルである「/version.html」が含まれていることが予想されます）。 私の疑問は主に責任の分割に関係しており、それぞれの適切な場所（検証、ビジネスルールなど）を見つけることです。以下に、コードをいくつか書き、質問と考慮事項を含むコメントを追加しました。 批判し、助言してください。前もって感謝します！ ドメインモデル すべてのビジネスルールをカプセル化するようにモデル化されています。 // Encapsulates logic for creating and validating Url's. // Based on "Unbreakable Domain Models", YouTube talk from Mathias Verraes // See https://youtu.be/ZJ63ltuwMaE public class Url: ValueObject { private System.Uri _uri; public string Url => _uri.ToString(); public Url(string url) { _uri …
4
複雑なドメイン中心のアプリケーションでの基本的なCRUD操作へのDDDアプローチ
私の会社はWebアプリケーションをゼロから書き直しています。これは、金融業界で複雑なドメインを持つ大規模なエンタープライズレベルのアプリケーションです。 永続化のためにORM（エンティティフレームワーク）を使用しています。 本質的に、アプリケーションの半分はユーザーから生データを収集して保存することに集中しており、実際のドメインロジックのほとんどを含むアプリケーションの残りの半分はその生データを使用して、元のデータとは大きく異なるドメイン画像を作成します生の入力、およびそれを計算エンジンに渡し、計算を実行し、結果を吐き出し、ユーザーに表示します。 レイヤーを使用したDDDアプローチでは、CRUD操作がドメインレイヤーを通過するように見えます。しかし、少なくとも私たちの場合、これは意味をなさないようです。 たとえば、ユーザーが編集画面に移動して投資口座を変更した場合、画面のフィールドはデータベースに保存されているフィールドそのものであり、後で計算に使用されるドメイン表現ではありません。では、編集画面でデータベース表現（生の入力）が必要なときに、なぜ投資口座のドメイン表現を読み込むのでしょうか。 ユーザーが投資口座画面で[完了]をクリックし、コントローラーに対してPOSTが実行されると、コントローラーには、保存する必要のある投資口座のほぼ正確なデータベース表現が表示されます。しかし、何らかの理由で、コントローラーのモデルをデータベースモデル（エンティティフレームワークモデル）に直接マッピングするのではなく、ドメイン表現をロードして変更を加えることになっていますか？ つまり、本質的には、データモデルをドメインモデルにマッピングします。これにより、永続化するためにデータモデルにマッピングし直すことができます。それはどういう意味ですか？
3
APIオブジェクトの定義にサードパーティの参照IDをプロパティとして含めるのは悪い習慣ですか？
このような： Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" referenceIdが心配です。 システムドメインは、さまざまな形式（xml、excel）のデータのエクスポートおよびインポートを通じて、サードパーティと多くの方法で統合されるプラットフォームです。サードパーティがAPIを介してシステムと統合できるように十分に成熟しており、このAPIの設計がこの疑問を引き起こします。 リソースを識別して取得するために使用できるIDを持つオブジェクト、キャンペーンがあります。APIの利用者は、ドメイン内のキャンペーンと見なすものへの独自の参照コードを持っている場合があります。 私たちのシステムには、このようなサードパーティの参照フィールドを持つ他のオブジェクトがあり、既存のコンシューマーから期待されています。ただし、マッピングの負担がかかり、このreferenceIdが何であるか（数値、テキスト、json？）がわからないため、新しいコンシューマー向けの混乱するプロパティがAPIに追加されます。 APIのパブリックオブジェクト定義でサードパーティの参照IDフィールドを許可することは、不適切な手法または不適切な設計と見なされますか？
4
境界付きコンテキストの境界を明確に定義する方法
1か月ほどDDDを読んで調査した後、私は自分のプロジェクトを開始することを決め、これらの制限されたコンテキストでDDDを作成しました> クライアント 製品 注文 課金 各境界付きコンテキストには、プレゼンテーション層、ドメイン層、永続層としてREST APIがあります。 これまでのところ、コードはスムーズに実行されていますが、モノリシックな世界から来ているので、私はまだ次のことを理解しようとしています： 新しいクライアントを作成したい場合、新しい請求書を発行したい場合、たとえば、国のアクセスリストなど、新しい注文を作成したい場合。私は： a）各BCの国のリストを作成する b）国BC-> APIを作成し、それを使用して利用可能な国のリストを取得する c）サードパーティのAPIを使用し、各BCの腐敗防止層を介してデータをプルする 破損防止レイヤーまたはアダプターレイヤーを使用してサードパーティAPIと統合する場合、ドメインモデルにどのデータを含める必要がありますか？たとえば、zendesk APIをクライアントBCと統合したい場合。ドメインにticketIDのみが必要ですか、それともクライアントBCでアクセスして使用するすべてのデータをZendeskから抽出する必要がありますか？ MVCアプリが実際にAPI（境界コンテキストのプレゼンテーションレイヤー）からデータを取得している場合、各BCの境界を明確に定義することは非常に困難です。それは、適切に設計されたBCが、追加のAPIを消費する必要なしに単一のMVCコントローラーを提供することを意味しますか？
2
エンティティの既知のビジネスIDは、DDD / OOPの専用タイプで表す必要がありますか？
実際には、カスタムタイプ（不変）classをstring他のプリミティブ型の上で使用することを意味します。 例： 出版：国際標準図書番号。 金融：国際証券識別番号。 利点： 識別子の形式を確認できます。 モデルのファーストクラスのメンバーになります。 短所： 永続化の摩擦を追加します（例：Entity Framework）。 より多くのコード。
4
DDD（またはセンス）との関係をモデル化しますか？
簡略化された要件は次のとおりです。 ユーザーがQuestion複数Answerのでを作成します。Question少なくとも1つ必要Answerです。 明確化：考えるQuestionとAnswer同様の試験：1つの質問がありますが、いくつかの答えは、どこ少数の正しいかもしれません。ユーザーはこのテストを準備している俳優なので、質問と回答を作成します。 この単純な例をモデル化して、1）実際のモデルと一致させ、2）コードで表現力を高め、誤用やエラーの可能性を最小限に抑え、開発者にモデルの使用方法のヒントを与えるようにしています。 質問はエンティティですが、回答は値オブジェクトです。質問は答えを保持します。これまでのところ、私はこれらの可能な解決策を持っています。 【A】工場内Question Answer手動で作成する代わりに、以下を呼び出すことができます。 Answer answer = question.createAnswer() answer.setText(""); ... これで回答が作成され、質問に追加されます。次に、プロパティを設定して回答を操作できます。このようにして、質問のみが回答を作成できます。また、迷わず回答させていただくこともございます。ただし、回答はでハードコーディングされているため、回答の作成を制御することはできませんQuestion。 上記のコードの「言語」には1つの問題もあります。ユーザーは質問ではなく回答を作成する人です。個人的には、値オブジェクトを作成するのが好きではありません。開発者に依存して値を入力します-どのように追加する必要があるかをどのように確認できますか？ [B]質問の中のファクトリー、＃2を取る この種のメソッドはQuestion次のようにすべきだと言う人もいます： question.addAnswer(String answer, boolean correct, int level....); 上記のソリューションと同様に、このメソッドは回答の必須データを取得し、質問にも追加されるデータを作成します。 ここでの問題は、正当な理由なくのコンストラクタを複製するAnswerことです。また、質問は本当に答えを作成しますか？ [C]コンストラクターの依存関係 両方のオブジェクトを自分で自由に作成してみましょう。依存関係の権利をコンストラクタで表現しましょう： Question q = new Question(...); Answer a = new Answer(q, ...); // answer can't exist without a question 質問がないと回答を作成できないため、これは開発者にヒントを与えます。ただし、質問に回答が「追加」されるという「言語」は見当たりません。一方、本当に見る必要がありますか？ [D]コンストラクターの依存関係、2番を取る 反対のことができます： Answer a1 …
2
DDD：不変オブジェクトもエンティティになることができますか？
私はエンティティと値オブジェクトの違いに関する無数の投稿を読んだことがあり、少なくとも概念的には2つがどのように異なるかを理解していると思いますが、これらの投稿の一部では、単に特定のドメインの概念をVOと見なしているようですは不変です（したがって、少なくともその特定のドメインモデル内では、その状態は決して変化しません）。 オブジェクトの状態が特定のドメインモデル内で決して変更されない場合、このオブジェクトがエンティティであってはならないことに同意しますか？どうして？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.