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

ドメイン駆動設計（DDD）は、実装をコアビジネスコンセプトの進化するモデルに深く結び付けることにより、複雑なニーズに対応するソフトウェアを開発するためのアプローチです。概念的なDDDの質問は、softwareengineering.stackexchange.comで尋ねる方がよいことに注意してください。

11
DAOとリポジトリのパターンの違いは何ですか？
データアクセスオブジェクト（DAO）とリポジトリパターンの違いは何ですか？Enterprise Java Beans（EJB3）、インフラストラクチャーとしてHibernate ORM、設計手法としてドメイン駆動設計（DDD）とテスト駆動開発（TDD）を使用してアプリケーションを開発しています。
7
DDDの良い例はどこにありますか？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 ドメインドリブンデザインについて学習していますが、いくつかの実用的な問題があり、いくつかの優れたサンプルを確認すると混乱する場合があります。 基本的なDDD概念のモデリングに優れた機能を果たすいくつかの優れたコードサンプルを知っている人はいますか？ 特に興味がある 例示的なドメインモデル リポジトリ ドメイン/アプリケーションサービスの使用 値オブジェクト 集合根
2
ドメイン駆動設計（DDD）とは何ですか？[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、1つの問題のみに焦点を当てますこの投稿を編集するます。 2年前休業。 この質問を改善する 記事でDDD（ドメイン駆動設計）が頻繁に使用されるのを見続けています。DDDに関するWikipediaのエントリを読みましたが、それが実際に何であり、自分のサイトの作成に実装する方法を理解できません。
8
ドメイン駆動設計：ドメインサービス、アプリケーションサービス
誰かがいくつかの例を提供することにより、ドメインとアプリケーションサービスの違いを説明できますか？また、サービスがドメインサービスの場合、このサービスの実際の実装をドメインアセンブリ内に配置します。そうであれば、そのドメインサービスにリポジトリも挿入しますか？いくつかの情報は本当に役に立ちます。
8
ドメイン駆動設計とは何ですか？
誰かが正確にドメイン主導の設計とは何かを簡潔に説明できますか？私はその用語をかなりよく見ますが、それが何であるか、またはそれがどのように見えるかを本当に理解していません。非ドメイン駆動設計とどう違うのですか？ また、誰かがドメインオブジェクトとは何かを説明できますか？ドメインは通常のオブジェクトとどのように異なりますか？
12
DDD-エンティティがリポジトリに直接アクセスできないルール
ドメイン駆動設計では、エンティティがリポジトリに直接アクセスしてはならないという多くの合意があるようです。 これは、Eric Evans Domain Driven Designによるものですか。本から来たのですか、それとも他の場所から来ましたか その背後にある推論についての良い説明はどこにありますか？ 編集：明確にするため：データアクセスをビジネスロジックとは別のレイヤーに分離する従来のOOプラクティスについて話しているのではなく、DDDではエンティティがデータに話しかけることを想定していない特定の配置について話しているアクセス層（つまり、Repositoryオブジェクトへの参照を保持することは想定されていません） 更新：彼の答えが最も近いようだったので、私はBacceSRに賞金を与えましたが、私はまだこれについてかなり暗いです。そのような重要な原則ならば、オンラインのどこかにそれについての良い記事があるはずです、きっと？ 更新：2013年3月、質問への賛成票はこれに多くの関心があることを意味し、多くの回答があったとしても、人々がこれについてアイデアを持っているなら、まだまだ余裕があると思います。
9
サービスは常にDTOを返す必要がありますか、それともドメインモデルも返すことができますか
大規模なアプリケーションを（再）設計しています。DDDに基づく多層アーキテクチャを使用しています。 データレイヤー（リポジトリの実装）、ドメインレイヤー（ドメインモデルとインターフェイスの定義-リポジトリ、サービス、作業単位）、サービスレイヤー（サービスの実装）を備えたMVCがあります。これまでのところ、すべてのレイヤーでドメインモデル（主にエンティティ）を使用し、ビューモデルとしてのみDTOを使用しています（コントローラーでは、サービスはドメインモデルを返し、コントローラーはビューに渡されるビューモデルを作成します）。 DTOの使用、使用、マッピング、および受け渡しに関する無数の記事を読んだことがあります。明確な答えはないことを理解していますが、ドメインモデルをサービスからコントローラーに返すかどうかはわかりません。ドメインモデルを返しても、コントローラーは常にビュー固有のビューモデルを作成するため、ドメインモデルはビューに渡されません。この場合、正当なようです。一方、ドメインモデルがビジネスレイヤー（サービスレイヤー）を離れると、適切に感じられません。サービスはドメインで定義されていないデータオブジェクトを返す必要がある場合があります。その場合、マップされていないドメインに新しいオブジェクトを追加するか、POCOオブジェクトを作成する必要があります（一部のサービスはドメインモデルを返すため、これは醜いです。効果的にDTOを返します）。 問題は、ビューモデルを厳密に使用する場合、ドメインモデルをコントローラーに返すことは問題ありませんか、それとも、サービスレイヤーとの通信に常にDTOを使用する必要がありますか？その場合、必要なサービスに基づいてドメインモデルを調整しても問題ありませんか？（率直に言って、私はそうは思いません。サービスはドメインが持っているものを消費する必要があるからです。）厳密にDTOに固執する必要がある場合、サービスレイヤーで定義する必要がありますか？（私はそう思います。）DTOを使用する必要があることは明らかです（たとえば、サービスが多くのビジネスロジックを実行して新しいオブジェクトを作成する場合）。ドメインモデルのみを使用する必要がある場合もあります（たとえば、Membershipサービスが貧血のUser（ s）-ドメインモデルと同じDTOを作成することはあまり意味がないようです）-しかし、私は一貫性と優れた実践を好みます。 記事ドメインvs DTO vs ViewModel-それらをいつどのように使用するか？（および他のいくつかの記事）は私の問題と非常に似ていますが、この質問には答えません。記事EFのリポジトリパターンでDTOを実装する必要がありますか？も同様ですが、DDDは扱いません。 免責事項：存在していてファンシーであるためにデザインパターンを使用するつもりはありません。一方、アプリケーション全体の設計に役立ち、分離に役立つため、優れたデザインパターンとプラクティスを使用したいと思います。特定のパターンを使用するのは難しいとしても、少なくとも現時点では「必要」ではありません。 いつもありがとうございます。
8
DTO = ViewModel？
NHibernateを使用してドメインオブジェクトを永続化しています。物事をシンプルに保つために、ASP.NET MVCプロジェクトをプレゼンテーションレイヤーとサービスレイヤーの両方として使用しています。 コントローラークラスからドメインオブジェクトをXMLで返したいのですが。Stack Overflowのいくつかの投稿を読んだ後、DTOを収集します。ただし、ViewModelについての投稿もありました。 私の質問：データ転送オブジェクトとViewModelは同じものですか？それともViewModelはDTOのサブパターンの一種ですか？
8
値とエンティティオブジェクト（ドメイン駆動設計）
DDDを読み始めたばかりです。EntityオブジェクトとValueオブジェクトの概念を完全に理解できません。ValueオブジェクトがEntityオブジェクトとして設計されているときにシステムが直面する可能性のある問題（保守性、パフォーマンスなど）を誰かに説明できますか？例は素晴らしいでしょう...
4
POSTアクションでビューモデルをドメインモデルにマップする方法は？
ViewModelsの使用とAutomapperの利用に関するインターネット上のすべての記事には、「コントローラー->ビュー」方向マッピングのガイドラインが記載されています。ドメインモデルとすべての選択リストを1つの特殊なViewModelに取り込み、それをビューに渡します。それは明らかで問題ありません。 ビューにはフォームがあり、最終的にはPOSTアクションになります。ここでは、すべてのモデルバインダーが、少なくともバインドと検証のための命名規則の一部で、元のViewModelに[明らかに]関連している[明らかに]別のビューモデルとともにシーンに登場します。 それをドメインモデルにどのようにマッピングしますか？ 挿入アクションとすると、同じオートマッパーを使用できます。しかし、それが更新アクションだった場合はどうなりますか？リポジトリからドメインエンティティを取得し、ViewModelの値に従ってそのプロパティを更新して、リポジトリに保存する必要があります。 補遺1（2010年2月9日）：モデルのプロパティを割り当てるだけでは不十分な場合があります。ビューモデルの値に従って、ドメインモデルに対して何らかのアクションを実行する必要があります。つまり、ドメインモデルでいくつかのメソッドを呼び出す必要があります。おそらく、ビューモデルを処理するために、コントローラーとドメインの間にある一種のアプリケーションサービスレイヤーが必要です... 次の目標を達成するために、このコードを整理する方法と配置する場所を教えてください。 コントローラを薄く保つ SoCの実践を尊重する ドメイン駆動設計の原則に従う 乾く つづく ...
14
ドメインエンティティをプレゼンテーション層から分離する必要があるのはなぜですか？
ドメイン駆動設計の一部で、詳細があまり詳しくないようですが、ドメインモデルをインターフェイスから分離する方法と理由です。これは良い習慣だと同僚に納得させようとしていますが、あまり進んでいないようです... プレゼンテーションレイヤーとインターフェイスレイヤーで、好きな場所でドメインエンティティを使用します。ドメインレイヤーをインターフェイスレイヤーから分離するために表示モデルまたはDTOを使用する必要があると私が主張するとき、彼らは、維持するUIオブジェクトがあるため、そのようなことを行うことでビジネス価値が見られないと反論します。元のドメインオブジェクトと同様に。 だから私はこれをバックアップするために使用できるいくつかの具体的な理由を探しています。具体的には： プレゼンテーション層でドメインオブジェクトを使用しないのはなぜですか？ （答えが明白なものである場合、「デカップリング」、それからこれがこの文脈で重要である理由を説明してください） ドメインオブジェクトをインターフェイスから分離するために、追加のオブジェクトまたは構成を使用する必要がありますか？
5
リポジトリを削減してルートを集約する
現在、データベース内のほぼすべてのテーブルのリポジトリがあり、それらを集約ルートのみに縮小することで、DDDとさらに整合させたいと考えています。 次のテーブルがあると仮定しましょう。 UserとPhone。各ユーザーは1つ以上の電話を持っている可能性があります。集約ルートの概念がなければ、私は次のようなことをするかもしれません： //assuming I have the userId in session for example and I want to update a phone number List<Phone> phones = PhoneRepository.GetPhoneNumberByUserId(userId); phones[0].Number = “911”; PhoneRepository.Update(phones[0]); 集合根の概念は、実際よりも紙の上で理解する方が簡単です。ユーザーに属していない電話番号を取得することは決してないので、PhoneRepositoryを廃止し、電話関連のメソッドをUserRepositoryに組み込むことは理にかなっていますか？答えが「はい」であると仮定して、前のコードサンプルを書き直します。 UserRepositoryに電話番号を返すメソッドを設定することはできますか？または、常にユーザーへの参照を返し、ユーザーを介して関係をトラバースして電話番号に到達する必要があります。 List<Phone> phones = UserRepository.GetPhoneNumbers(userId); // Or User user = UserRepository.GetUserWithPhoneNumbers(userId); //this method will join to Phone どちらの方法で電話を入手したとしても、そのうちの1つを変更したとすると、どうすれば更新できますか？私の限られた理解は、ルートの下のオブジェクトはルートを介して更新する必要があるということです。これにより、以下の選択肢1に進むことができます。これはEntityFrameworkで完全に機能しますが、コードを読んでいると、Entity Frameworkがグラフ内の変更されたオブジェクトを監視しているにもかかわらず、実際に何を更新しているのかわからないため、これは非常にわかりにくいようです。 UserRepository.Update(user); // …
5
ドメインオブジェクト、POCO、エンティティの違いは何ですか？
基本的には同じだという印象を受けました。モデルオブジェクトも同じですか？ 現在、私のアーキテクチャでは、次のことがあります。 class Person { public string PersonId; public string Name; public string Email; public static bool IsValidName() { /* logic here */ } public static bool IsValidEmail() { /* logic here */ } } class PersonService { private PersonRepository pRepository; PersonService() { pRepository = new PersonRepository(); } public bool …
3
Entity Framework Coreの強く型付けされたID
私は強く型付けされたIdクラスを作ろうとしていますが、これは内部で「long」を保持しています。以下の実装。私のエンティティでこれを使用している問題は、Entity Frameworkから、プロパティIDが既にマッピングされているというメッセージが表示されることです。IEntityTypeConfiguration以下を参照してください。 注：私は厳密なDDD実装を目指していません。したがって、コメントや回答の際には、このことを覚えておいてください。型付けの背後にあるID全体Idは、すべてのエンティティでIdを使用するように強く型付けされているプロジェクトにアクセスする開発者向けです。もちろんlong（またはBIGINT）に翻訳されますが、他の人にとっては明らかです。 動作しないクラスと構成の下。リポジトリはhttps://github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31にあります。 Id（現在コメントアウトされている）のクラス：https : //github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/blob/master/Source/Common/Kf.CANetCore31/DomainDrivenDesign/Id.cs EntityおよびValueObjectクラス（EntityプロパティIdのタイプはId.cs（上）でした：https : //github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/tree/master/Source/Common/Kf.CANetCore31/DomainDrivenDesign 構成：https : //github.com/KodeFoxx/Kf.CleanArchitectureTemplate.NetCore31/tree/master/Source/Infrastructure/Persistence/Kf.CANetCore31.Infrastructure.Persistence.Ef/EntityTypeConfigurations Idクラスの実装（これは解決策が見つかるまでアイデアを放棄したため、現在は使用されていません） namespace Kf.CANetCore31.DomainDrivenDesign { [DebuggerDisplay("{DebuggerDisplayString,nq}")] [Obsolete] public sealed class Id : ValueObject { public static implicit operator Id(long value) => new Id(value); public static implicit operator long(Id value) => value.Value; public static implicit operator Id(ulong value) => …
3
同じエンティティを異なるテーブルにマッピングする
ドメインに関する知識 商品の支払いや払い戻しを可能にするPOS（Point Of Sales）ソフトウェアを書いています。支払いまたは払い戻しの際、使用する送金方法を指定する必要があります：現金、銀行口座振込（〜=クレジットカード）、ポイントカード、バウチャーなど。 これらの送金手段は、有限で既知の値のセット（列挙型の一種）です。 トリッキーな部分は、支払いと払い戻しの両方（2つのセットは異なる場合があります）のためにこれらの手段のカスタムサブセットをPOS端末に保存できる必要があることです。 例えば： 利用可能な支払い手段：現金、EFT、ポイントカード、バウチャー 利用可能な払い戻し手段：現金、バウチャー 実施の現状 私は次のように送金手段の概念を実装することを選択します： public abstract class MoneyTransferMean : AggregateRoot { public static readonly MoneyTransferMean Cash = new CashMoneyTransferMean(); public static readonly MoneyTransferMean EFT = new EFTMoneyTransferMean(); // and so on... //abstract method public class CashMoneyTransferMean : MoneyTransferMean { //impl of abstract method …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.