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

私は過去にMDA（モデル駆動型アーキテクチャ）ツールを使用しましたが、UMLを介してモデル化し、これにより、とりわけビジネスエンティティ（ドメインモデル）とORM（マッピングなど）が生成されました。 ドメインで動作するビジネスコードとサービスの多くはモデルの一部であり、リポジトリはビジネスエンティティを返していました（そのため、別のORMに切り替えることはできませんでした（望んでいなかった））。 しかし、今はプロジェクトを始めており、DDDについて考えたいと思います。 これまでのところ、ビジネスロジックをドメインモデルに入れ、リポジトリを介してORM（どちらを選択した場合でも）で作業するように感じています。ただし、アプリケーションのORM部分に引き続きMDAツールを使用したい場合、ここで作成されたモデルは非常に貧弱です（つまり、ビジネスロジックが含まれていません）。同様に、ORMにエンティティフレームワーク（.net）またはNHibernateを使用した場合、それも貧血モデルになります。NHibernateをそのまま使用した場合、ビジネスロジックをどこに置くかわかりません。 私はこのように考えるのは正しいですか、つまりDDDではドメイン内のすべてのビジネスロジックを使用し、リポジトリ経由で永続化するためにORMを使用するだけですか？

10 orm  entity-framework  domain-model  nhibernate  domain-driven-design 

私は比較的DDDの初心者ですが、知識を沸騰させて蒸留するために手に入れることができるあらゆるものを読んでいます。 私はこのDDDの質問に出くわし、その答えの1つに興味をそそられました。 DDDバウンドコンテキストとドメイン？ 回答の1つで、ポスターは、製品が少なくとも2つのドメインにあるeコマースシステムの例を示しています。 1）製品カタログ2）在庫管理 わかりました。つまり、eコマースのフロントエンドでは、商品情報の表示に関心があり、在庫管理には関心がありません。 だが。Webページに在庫レベルを表示したり、在庫のエディション番号を表示したりすることができます（在庫が本、雑誌などであるとします）。この情報は、インベントリドメインから取得されます。 それで、これをどのように処理しますか？あなたは a）製品ドメインと在庫ドメインの両方の集合体をロードしますか？b）在庫数と在庫数の製品ドメインエンティティの一部のプロパティを保持し、在庫エンティティが更新されたときにドメインイベントを使用してこれらを更新しますか？ 最後の質問です。私たちはドメインの永続性を忘れ/無視し、ドメインについて考えることを意図していることを知っています。しかし、これをよく考えてみると、上の例では、製品カタログと製品在庫用に2つのDBテーブルが存在する可能性があります。これらは同じ製品なので、同じ識別子を使用しますか？または、データに1つのテーブルと1つのテーブル行を使用して、関連するデータを集計プロパティに単純にマップできますか？

10 domain-driven-design  domain-model 

これは、この質問にいくぶん似ていますが、より広義です。 一般的には、EF 4.1のようなオームズはPOCOSをサポートし、それは今あなたのドメインエンティティを持ってしても意味がないことがデータベースに永続化されたオブジェクト？ EF 4やLinq-to-SQLなどの古いORMでは、「データベースオブジェクト」が自動生成され、データベースに密結合されていたため、重要なアプリケーションの場合、より堅牢でインテリジェントなドメインエンティティにマッピングされていました。就職。 新しいORMを使用して堅牢なドメインエンティティを構築し、そのドメインエンティティとDBMSの間のマッピングを提供するだけのデータレイヤーを作成するという考えはありますか？ 書面では、これが常に目標であると感じていますが、少なくとも.NETの世界では、利用可能なツールを使用して（簡単に）簡単に実現することはできません。

10 orm  domain-driven-design  entity-framework  domain-model 

実際には、カスタムタイプ（不変）classをstring他のプリミティブ型の上で使用することを意味します。 例： 出版：国際標準図書番号。 金融：国際証券識別番号。 利点： 識別子の形式を確認できます。 モデルのファーストクラスのメンバーになります。 短所： 永続化の摩擦を追加します（例：Entity Framework）。 より多くのコード。

9 object-oriented  domain-driven-design  domain-model  entity  value-object 

簡略化された要件は次のとおりです。 ユーザーが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 …

9 design  domain-driven-design  domain-model 

私はDDDから始めて、国境を越えた一貫性を確保するために集約ルートが使用されることを理解しています。1つのアプリケーションサービスで複数の集計を変更しないでください。 ただし、次のような場合の対処方法を教えてください。 Productsという集約ルートがあります。 グループと呼ばれる集約ルートもあります。 どちらにもIDがあり、個別に編集できます。 複数の製品が同じグループを指すことができます。 製品のグループを変更できるアプリケーションサービスがあります。 ProductService.ChangeProductGroup(string productId, string groupId) チェックグループが存在する リポジトリから製品を取得する グループを設定する 製品をリポジトリに書き戻す グループを削除できるアプリケーションサービスもあります。 GroupService.DeleteGroup(string groupId) 1. groupIdが提供されたgroupIdに設定されているリポジトリから製品を取得し、カウントが0または中止であることを確認します2.グループリポジトリからグループを削除します3.変更を保存します 私の質問は、次のシナリオです。 ProductService.ChangeProductGroupで、グループが存在することを確認し（存在する場合）、この確認の直後に、別のユーザーが（他のGroupService.DeleteGroupを介して）productGroupを削除します。この場合、削除されたばかりの製品への参照を設定しますか？ これは、別のドメイン設計を使用する必要がある（必要に応じて追加の要素を追加する）か、トランザクションを使用する必要があるという点で、私の設計の欠陥ですか？

9 domain-driven-design  domain-model 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私は過去数ヶ月間、ZendのMVC実装と組み合わせてOOPを研究してきました。私は一般的に、プログラミングにはかなり新しいですが、私は物事に必ず私が理解することを意味私のための「正しい」方法で、学ぶべきだと強く感じ、なぜ物事は彼らが道をやっているし。つまり、何かを行う方法（何かを言う、音楽など）を学ぶ上で、何かを行う方法を学ぶ最善の方法は、そもそもなぜそのように行われるのかを知ることであることがわかりました。 とにかく、私は自分のビジネスモデル（つまりMVCのM）を開発する方法を理解するのに非常に苦労してきました。OOPを一般的に理解していないからではないと判断しました。数ヶ月、私は概念を理解することは非常に難しいとは思いません。私が研究した例は、実際には非常に直感的です。私の問題は、私自身の問題をオブジェクト指向のソリューションに変換するプロセスにあると思います。本の例（私がこれまでに読んだもの）は明白すぎるため、問題をオブジェクトに変換するプロセスはそれほど難しくありません。私が見落としているのは、高レベルの抽象化されたプロセスです。すべてのオブジェクト指向ソリューションが最高レベルで回答する必要があるステップまたは質問のある種のリスト。 このようなプロセスを5ステップ以内で説明する必要がある場合、それらはどのようなもので、その理由は何ですか。問題をオブジェクト指向のソリューションに変換する最も効果的なプロセスは何ですか？

9 object-oriented  mvc  domain-model  business-logic 

「標準」の考え方はソフトウェアに広まっています。Canonical Model、Canonical Schema、Canonical Data Modelなどのパターンは、開発中に何度も登場するようです。 多くの開発者と同様に、私は頻繁に、批判的ではないが、正規モデルが必要であるという従来の知恵に従いました。それ以外の場合は、マッパーとトランスレーターの組み合わせの爆発に直面します。または、少なくとも、数年前にやや悪名高いEFの「自信なしの投票」を初めて読んだときまで、私はそれを行っていました。 正規データモデルの追求をかつて支持していたという仮説は、そのアイデアが実践されたときに発見されるであろう要因を含まず、含めることもできませんでした。長年の試行錯誤の結果、正規データモデルが使用される可能性のある個々のコンテキストに個別のモデルを使用することが、最も複雑なアプローチではなく、最もコストのかからないアプローチであり、保守性と拡張性の向上につながります。コンテキストモデルを使用したアプリケーションとエンドポイントの比較。これは、正規モデルが行うソフトウェアエントロピーを促進しないアプローチです。 エッセイはその主張を裏付けるいかなる種類の証拠も提示していませんが、代替案を試すのに十分長い間CDMアプローチに疑問を投げかけ、結果のソフトウェアは文字通りまたは比喩的に爆発しませんでした。しかし、それだけですべてが孤立しているわけではありません。運が良かっただけかもしれません。 ですから、ソフトウェアシステムまたはアーキテクチャに標準モデルとコンテキストモデルを組み合わせた場合の実際的な長期的な影響について、真剣な調査が行われたのでしょうか。 あるいは、それを尋ねるのが早すぎる場合は、開発者/アーキテクトに、CDMから独立したコンテキストモデルへの（またはその逆の）CDMから個人的なエクスペリエンスへの切り替えについて書いてもらい、生産性、複雑さ、信頼性などの実際的な影響は何でしたか？ 異なるレベルでの違いについてはどうでしょうか。つまり、単一のアプリケーションで同じモデルを使用する場合と、アプリケーションのシステムまたは企業全体で使用する場合の違いはどうでしょうか。 （事実のみ、お願いします。戦争の話は大歓迎ですが、憶測はありません。）

9 design-patterns  architecture  data  domain-model 

次のように定義されたデータベーススキーマがあるとします。 Person.mail_address_key ----- Address.address_key Person.billing_address_key ----- Address.address_key A Personには郵送先住所と請求先住所があります。非正規化手法として、別のAddressテーブルを作成します。時間のほとんどは、mail_address_keyおよびbilling_address_key単一のはPerson同じ値になります（例：自分の郵送や請求先住所のキーが同じになります）。 私のデータベースでAddressは、IDがあります（アドレスキー）。しかし、私のドメインモデルではAddress、がエンティティになる説得力のある理由はわかりません。値オブジェクトにしたいのですが。 DDDでは、これはオプションですか？または、値オブジェクトは通常、（テーブルではなく）列のグループですか？データベースがドメインモデルの構造を指示するべきではないと思うので、ここでは悪魔の擁護者を演じています。 もしそうなら、アドレスはどこで/いつ/どのようにデータベースのアイデンティティを失うので、ドメインレイヤーの値オブジェクトとして使用できますか？または、データベース識別子を値オブジェクトに保持することになっていますか？ モデルをデータベースに永続化する必要がある場合、プロセスは何ですか？私はa）これらのフィールドでアドレスを検索し、b）存在しない場合は新しいアドレスを作成しますc）存在する場合はフィールドを更新しますか？

8 domain-driven-design  domain-model  value-object 

ドメインモデルファクトリを実装する方法と場所を理解しようとしています。Company集計を、それをどのように行ったかのデモとして含めました。 私は最後に私の設計決定を含めました-それらの点に関するコメント、提案、批評をいただければ幸いです。 Companyドメインモデル： public class Company : DomainEntity, IAggregateRoot { private string name; public string Name { get { return name; } private set { if (String.IsNullOrWhiteSpace(value)) { throw new ArgumentOutOfRangeException("Company name cannot be an empty value"); } name = value; } } internal Company(int id, string name) { Name …

8 design  domain-driven-design  domain-model  architectural-patterns 

作業しているWebベースのアプリケーション用のシンプルなRESTful APIを構築しています。ドメインモデルを公開するための最良の方法について考えています。 Userクラスがあり、JSONレスポンスにさまざまなユーザープロパティを提供したいとします。セキュリティと帯域幅の問題のため、モデルのすべてのプロパティ（DateCreated、PasswordHashなど）を公開したくないのは明らかです。 私はデータ転送オブジェクトを読みましたが、これが進むべき道かどうか疑問に思っています。私が正しい場合、たとえば、ユーザーモデルをユーザーDTOに渡し、そのDTOが選択したユーザープロパティの公開のみを許可することを確認できます（これは、モデルをパブリックAPIから分離するのにも役立ちます）。 この解決策は適切ですか、またはこれについてより良い方法がありますか？ ありがとう。

8 language-agnostic  api  domain-model 

人々は「3層（またはn層）アーキテクチャ」に従っているとしばしば主張し、時にはドメインモデルに切り替えると主張することもあります。しかし、私はこの神秘的な「3層アーキテクチャ」が何であるかを本当に理解したことがありません。正式な定義がないようです。ドメインモデルパターンを説明およびデモする参照や例は数多くありますが、3層への参照は、コードをUI、ビジネスロジック、およびデータアクセスレイヤーに分離することを示唆しています。そして、それは彼らが言うように見えるすべてです。 私が特に奇妙だと思うのは、ドメインモデルは、この3層のパラダイムを完璧に具現化したものだということです。ORMファイルとマッピングファイルはデータアクセスレイヤー、ドメインはビジネスロジック、UIはUIです。それではなぜ人々はそれが新しい何かであり、彼らが切り替えるべきものであるかのように話すのですか？ ドメインモデルを実装している人を見る前は、ほとんどのアプリケーションはUIであり、ロジックはUIとSPに分割されたストアドプロシージャにアクセスしていました。「UI」、「BLL」、「DLL」と呼ばれるいくつかのアセンブリが時々ありましたが、通常これらは単にUIとSP間のメディエーターであり、ロジックがランダムに分散するためのより多くの場所を残しました。 では、この神秘的な「3層」アーキテクチャとは何でしょうか。それは本当に存在していますか？もしそうなら、それがうまく実装されている例はどこにありますか？

8 architecture  domain-model  n-tier