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

ドメインイベントハンドラーをDDDに配置するのに適したレイヤーはどれかという意見を教えてください。たとえば、新しい契約を追加するアプリケーションサービスがあり、契約が追加されたときに連絡先に電子メール通知を送信したいので、その電子メール送信者（ContractAddedイベントを処理する）アプリケーションサービスまたはドメインサービスまたは他に何か？

13 domain-driven-design  event 

DDDリポジトリの典型的な実装は、save()メソッドなど、あまりオブジェクト指向ではありません。 package com.example.domain; public class Product { /* public attributes for brevity */ public String name; public Double price; } public interface ProductRepo { void save(Product product); } インフラストラクチャ部分： package com.example.infrastructure; // imports... public class JdbcProductRepo implements ProductRepo { private JdbcTemplate = ... public void save(Product product) { JdbcTemplate.update("INSERT INTO …

12 design-patterns  object-oriented  domain-driven-design 

最初の免責事項：この質問がこのウェブサイトに適合するかどうかはわかりませんが、私だけでなく、初心者である他の人にとっても関連する質問であることに変わりはありません。ここに収まるように質問を改善できる場合は、intコメントを指摘してください。それが合わない場合は、私にも知らせてください。可能であれば、これに関する良いフォーラムが見つからなかったので、これについて議論できる場所を教えてください。 私はPHPを勉強した2009年にプログラミングを学びました。2012年の後半に、C＃と.NETに移行しました。とにかく、コーディングは問題ではなく、アルゴリズムを書き留めることは私の問題ではありません。私の実際の問題は、要件を達成するために何をコーディングする必要があるか、どこでコーディングする必要があるかを知ることです。 Web上で利用できるそこにほとんどのコースは対処方法ここでは私のポイントではないなど、いくつかのAPIセットを使用する方法、特定の言語でコードを書く方法を- 。 ここ数年、オブジェクト指向の分析と設計、設計パターン、ドメイン駆動設計など、たくさんのことを読みました。たとえば、SOLIDの原則、ドメインエキスパートの関与の必要性、ユビキタス言語の開発など、DDDの主要なアイデアのいくつかを理解しています。少なくとも理にかなった理論的背景があると思います。 しかし、それが練習になると、私は災害だと感じます。しばらく前に、私はすでに他の誰かによって開発されていた金融システムの開発を続ける必要がありました。それは、C＃とWinFormsで開発されたそのような「古いシステム」です。実際のドメインの複雑さ、多くのビジネスルールなどを含むプロジェクトを選んだのは初めてでした。 ほとんどの場合、要件を受け取ったとき、「一体どうやってこれを行うことができるのか」と思います。-どうすればよいのかを理解するために、要件の作業を開始する方法すらわからない。私が信じている主な混乱は、私がコーディングしなければならないもの、クラス、インターフェース、そして各ロジックがどこに行くのか、各クラスがどのクラスにあるべきなのかです。問題は、どこから始めればいいかわからないことです。 ほとんどの場合、非常に多くの考えでいくつかのアイデアになりますが、私のアイデアが正しいかどうかを判断する方法がわかりません。 推奨されたソフトウェアアーキテクチャとオブジェクト指向に関する多くのことを読んだと言ったので、これは理論の欠如ではないと思いますが、実際には何をしなければならないかを特定するのにはあまり役立ちませんでした。 それでは、どうすればオブジェクト指向設計を実際に 行うことができますか？私が学びたいのは、与えられた要件は、何をすべきか、各コードがどこに属しているかを見つけるプロセスでそれらに取り組む方法を知っていることです。自分の考えが正しいかどうかを判断する方法を学ぶにはどうすればよいですか？ ここで答えとしてこれを完全に説明することは不可能だと思います。しかし、私が探しているのは、サイトのスタイルに応じて、単に概要を示し、アイデアを拡大し、これらのことを実際に学習するために使用できる参照（書籍、オンラインコースなど）を示す回答です。

12 architecture  object-oriented-design  domain-driven-design  requirements  engineering 

永続性無知は、単一の責任原則のアプリケーションです。実際には、ドメインオブジェクト（DO）に永続性に関連するコードを含めるべきではなく、ドメインロジックのみを含める必要があります。 a）これは、下位層（つまり、永続層）に接続するコードが、ビジネスロジック層の他のクラス（OC）のドメインモデルの外側にあることを意味すると思いますか？ b）の下で、私の仮定した場合）正しいこと、そしてDOたとえば、Customer、決してなどの方法が含まれていませんGetCustomersかGetCustomerByID？ c）a）およびb）の下での私の仮定が正しく、Customerドメインオブジェクトがそのプロパティの一部に遅延読み込みを使用すると仮定すると、ある時点でCustomer内部ロジックがOCに連絡し、次にOCが遅延データを取得する必要があります。しかし、遅延データを受け取るためにOCCustomerに連絡する必要がある場合、ドメインオブジェクトに永続性に関連するロジックが含まれていないことを主張することはできません。 ありがとうございました jkohlheppへの返信 1）クラスはビジネスロジック層に含まれているOrderProviderと思いCustomerProviderますか？ 2）b）の下での私の仮定が正しいというあなたの返事から集めますか？ 3） ...いくつかの非公開注文フィールドが入力されているか、それがヌルであるかを確認します。nullの場合... しかし、私が知る限り、ドメインコードがプライベートorderフィールドに入力されているかどうかを確認する必要があるとすぐに、もしそうでない場合はOrderProviderに問い合わせると、すでにPIの原則に違反していますか？！

12 design-patterns  domain-driven-design  domain-model  persistence 

私は数日間DDDについて読みましたが、このサンプルデザインの支援が必要です。ドメインオブジェクトがアプリケーション層にメソッドを表示することを許可されていない場合、DDDのすべてのルールにより、どのように構築するかについて非常に混乱しています。行動を調整する他の場所は？リポジトリーをエンティティーに注入することは許可されていないため、エンティティー自体が状態で動作する必要があります。次に、エンティティはドメインから何か他のものを知る必要がありますが、他のエンティティオブジェクトも注入することはできませんか？これらのことのいくつかは私には理にかなっていますが、いくつかはそうではありません。すべての例は注文と製品に関するものであり、他の例を繰り返し繰り返しているため、機能全体を構築する方法の良い例をまだ見つけていません。私は例を読むことで最もよく学び、これまでにDDDについて得た情報を使用して機能を構築しようとしました。 私が間違っていることとそれを修正する方法を指摘するためにあなたの助けが必要です。エンティティを別のエンティティに注入できない場合、適切に実行する方法を簡単に確認できます。 私の例では、ユーザーとモデレーターがいます。モデレーターはユーザーを禁止できますが、ビジネスルールがあります：1日あたり3人のみです。関係を示すためにクラス図を設定しようとしました（以下のコード）： interface iUser { public function getUserId(); public function getUsername(); } class User implements iUser { protected $_id; protected $_username; public function __construct(UserId $user_id, Username $username) { $this->_id = $user_id; $this->_username = $username; } public function getUserId() { return $this->_id; } public function getUsername() { return $this->_username; } …

12 architecture  domain-driven-design 

DDDアプローチを使用して、肥大化したサービスレイヤーからドメインレイヤーにデータを移動しようとしています。現在、私たちのサービスには多くのビジネスロジックがありますが、それはいたるところに分散しており、継承の恩恵は受けません。 ほとんどの作業の中心である中央ドメインクラスがあります-貿易。Tradeオブジェクトは、それ自体の価格設定方法、リスクの推定方法、それ自体の検証方法などを知っています。その後、条件をポリモーフィズムに置き換えることができます。例えば、SimpleTradeはそれ自体の価格を設定しますが、ComplexTradeはそれ自体の価格を設定します。 ただし、これによりTradeクラスが膨張するのではないかと心配しています。本当に独自の処理を担当する必要がありますが、機能が追加されるにつれてクラスのサイズは指数関数的に増加します。 選択肢があります： Tradeクラスに処理ロジックを配置します。処理ロジックは現在、取引のタイプに基づいてポリモーフィックですが、取引クラスには複数の責任（価格、リスクなど）があり、大規模です TradePricingServiceなどの他のクラスに処理ロジックを配置します。Trade継承ツリーとポリモーフィックではなくなりましたが、クラスは小さくなり、テストが容易になりました。 推奨されるアプローチは何ですか？

12 object-oriented  design  domain-driven-design 

私は最近、エンティティフレームワークのような強力なORMでリポジトリパターンを使用することに対して多くの議論を読みました。リポジトリパターンは作業単位機能とともにリポジトリに似た機能を組み込んでいるからです。 単体テストのような状況でパターンを使用することに対するもう1つの論点は、より汎用的な実装がIQueryableを活用するため、リポジトリパターンは漏れやすい抽象化であるということです。 リポジトリパターンの使用に反対する議論は私には理にかなっていますが、提案された抽象化の代替方法はしばしば混乱を招き、問題と同じくらいやり過ぎです。 Jimmy Bogardsのソリューションは、抽象概念を吹き飛ばすことと、彼自身のアーキテクチャを導入することの組み合わせのようです。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ リポジトリが不必要になっている別の例....しかし、私のアーキテクチャを使用してください！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 別の... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 私は、それ自体が設計されていない「過度に複雑な」リポジトリパターンアプローチの明確な代替物や代替物を見つけていません。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

私は基本的に、CQRSの概念と関連する概念に頭を包み込もうとしています。 CQRSには必ずしもメッセージングとイベントソーシングが組み込まれているわけではありませんが、適切な組み合わせのようです（これらの概念を組み合わせた多くの例/ブログ投稿でわかるように） 何かの状態変更のユースケース（SOに関する質問を更新するなど）が与えられた場合、次のフローが正しいと考えますか（ベストプラクティスとして）。 システムは、いくつかの小さなコマンドに分割される可能性のある集約UpdateQuestionCommandを発行します。質問集約ルートをターゲットとするUpdateQuestion、およびユーザー集約ルートをターゲットとするUpdateUserAction（ポイントをカウントするなど）。これらは、ポイントツーポイントメッセージングを使用して非同期的に送信されます。 集約ルートはそれぞれの処理を実行し、すべてがうまくいけば、QuestionUpdatedイベントとUserActionUpdatedイベントをそれぞれ起動します。これらのイベントには、イベントストアに外部委託された状態が含まれます。 これらのイベントは、ブロードキャスト用のpub / subキューにも置かれます。サブスクライバー（読み取りビューを作成する1つまたは複数のプロジェクターの可能性が高い）は、これらのイベントを無料でサブスクライブできます。 一般的な質問：コマンドはPoint-to-Pointで通信される（つまり、受信者が既知である）のに対して、イベントはブロードキャストされる（つまり、受信者が不明である）ことは本当にベストプラクティスですか？ 上記を仮定すると、ポイントツーポイントではなくpub / subを介してコマンドをブロードキャストすることの利点/欠点は何でしょうか？ 例：佐賀はどの集約ルートが最初に参加するのかわからないため、集約ルートの1つに障害が発生した場合に佐賀が果たす必要がある調停の役割が妨げられるため、佐賀の使用中にコマンドをブロードキャストすることが問題になる可能性があります。 一方、コマンドのブロードキャストが許可されると、利点（柔軟性）が得られます。

12 domain-driven-design  cqrs  event-sourcing 

ドメイン駆動設計では、ドメイン層にいくつかの（従来の）サービスを含めることができます。たとえば、ユーザードメインの場合、次のようになります。 さまざまな方法でUserオブジェクトを構築するUserFactory インフラストラクチャレイヤーの永続サービスとの対話を担当するUserRepository ドメインレイヤーのUserServiceは、これら2つのサービスとインフラストラクチャレイヤーのメディエーターやファサードにすぎませんか、それともそれ以上ですか？

12 object-oriented  object-oriented-design  domain-driven-design 

私はドメイン駆動設計（DDD）の概念に飛び込んでいますが、特にドメインと永続性モデルの分離に関して、いくつかの原則が奇妙であることに気付きました。これが私の基本的な理解です： （機能セットを提供する）アプリケーション層のサービスは、その機能を実行するために必要なリポジトリからドメインオブジェクトを要求します。 このリポジトリの具体的な実装は、それが実装されたストレージからデータをフェッチします サービスは、ビジネスロジックをカプセル化するドメインオブジェクトに、その状態を変更する特定のタスクを実行するように指示します。 サービスは、変更されたドメインオブジェクトを永続化するようリポジトリに指示します。 リポジトリは、ドメインオブジェクトをストレージ内の対応する表現にマップする必要があります。 さて、上記の仮定を考えると、以下は厄介なようです： 広告2 :: ドメインモデルは、ドメインオブジェクト全体（すべてのフィールドと参照を含む）をロードしているように見えます。それを要求した関数には必要ない場合でもです。他のドメインオブジェクトが参照されている場合は、それらのドメインオブジェクトとそれらが参照しているすべてのオブジェクトを順にロードしない限り、完全にロードすることさえ不可能かもしれません。遅延読み込みが思い浮かびますが、これは、最初にリポジトリの責任であるドメインオブジェクトのクエリを開始することを意味します。 この問題を考えると、ドメインオブジェクトをロードする「正しい」方法には、各ユースケースに専用のロード関数があるようです。これらの専用関数は、それらが設計されたユースケースで必要なデータのみをロードします。ここで、ぎこちないことが出てきます。最初に、リポジトリの実装ごとにかなりの量のロード関数を維持する必要があり、ドメインオブジェクトはnull、フィールドを運ぶ不完全な状態になってしまいます。後者は、値がロードされなかった場合でも、それを要求した機能によって要求されるべきではないため、技術的には問題になりません。それでも厄介で潜在的な危険です。 広告3 :: ドメインオブジェクトは、リポジトリの概念がない場合、構築時に一意性の制約をどのように検証しますか？たとえばUser、一意の社会保障番号（指定されている）を使用して新しいを作成する場合、データベースに一意性制約が定義されている場合にのみ、リポジトリにオブジェクトの保存を要求すると、最も早い競合が発生します。それ以外の場合はUser、指定された社会保障でを探し、それが存在する場合は、新しいものを作成する前にエラーを報告できます。ただし、制約チェックはサービスに存在し、それらが属するドメインオブジェクトには存在しません。私はドメインオブジェクトが検証のために（注入された）リポジトリを使用することが非常によく許可されていることに気づきました。 広告5 .: 私は、ドメインオブジェクトのストレージバックエンドへのマッピングを、ドメインオブジェクトが基になるデータを直接変更するのと比較して、作業集約的なプロセスとして認識しています。もちろん、具体的なストレージ実装をドメインコードから切り離すことは、必須の前提条件です。しかし、それは確かにそのような高コストで来るのでしょうか？ ORMツールを使用してマッピングを行うオプションがあるようです。ただし、ORMの制限に従ってドメインモデルを設計する必要がある場合や、ドメインからインフラストラクチャレイヤーへの依存関係を導入する必要がある場合もあります（たとえば、ドメインオブジェクトでORMアノテーションを使用するなど）。また、私はORMがかなりの計算オーバーヘッドをもたらすことを読みました。 ORSQLのような概念がほとんど存在しないNoSQLデータベースの場合、ドメインモデルで変更されたプロパティをどのように追跡しますsave()か？ 編集：また、リポジトリがドメインオブジェクトの状態（つまり、各フィールドの値）にアクセスするためには、ドメインオブジェクトがカプセル化を解除する内部状態を明らかにする必要があります。 一般に： トランザクションロジックはどこに行きますか？これは確かに永続化に固有のものです。一部のストレージインフラストラクチャは、トランザクションをまったくサポートしない場合もあります（インメモリモックリポジトリなど）。 複数のオブジェクトを変更する一括操作の場合、オブジェクトのカプセル化された検証ロジックを通過するために、各オブジェクトを個別にロード、変更、および保存する必要がありますか？これは、データベースに対して単一のクエリを直接実行することとは対照的です。 このトピックについて、いくつかの説明をお願いします。私の仮定は正しいですか？そうでない場合、これらの問題に取り組む正しい方法は何ですか？

12 domain-driven-design  domain-model  persistence 

私が理解しているように、DDDでは、集約ルートでリポジトリパターンを使用することが適切です。私の質問は、データをエンティティまたはドメインオブジェクト/ DTOとして返す必要がありますか？ たぶんいくつかのコードが私の質問をさらに説明するでしょう： エンティティ public class Customer { public Guid Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } } このようなことをする必要がありますか？ public Customer GetCustomerByName(string name) { /*some code*/ } またはこのようなもの？ public class CustomerDTO { public Guid Id { get; set; …

11 c#  domain-driven-design  repository-pattern 

イベントソーシングと一緒にCQRSパターンを使用して、最初のアプリケーションを実装します。集約ルートの作成を適切に処理する方法について疑問に思っています。誰かがCreateItemコマンドを送信したとしましょう。どのように処理する必要がありますか？イベントItemCreatedを保存​​する場所 新しいアイテムの最初のイベントとして？または、すべてのアイテムを集約し、そのイベントリストがItemCreatedイベントのみで構成される、何らかの種類のItemListエンティティが必要ですか？ Udi Dahan は、集約ルートを作成せず、常に何らかのフェッチメソッドを常に使用することを提案しています。しかし、新しいもので、IDが割り当てられていないものを取得する方法。私は背後にある考え方を理解しており、新しいオブジェクトは、それに応答するイベントがゼロで構成される状態を持つオブジェクトであると考えるのはかなり合理的です。しかし、どのように使用すればよいですか？私のような私のリポジトリに明確な方法を持っていなければならないgetNewItem()か、私の作るget(id)方法を受け入れてOptional<ItemId>代わりに？ 編集：しばらく掘り下げた後、アクターを使用した前述のパターンの非常に興味深い実装を見つけました。作成者は、集計を作成する代わりに、新しく作成されたUUIDを使用して、何らかの種類のリポジトリからそれを取得します。このアプローチの欠点は、一時的な不整合状態を許容することです。またdelete、このようなアプローチでメソッドを実装する方法を疑問に思っています。削除済みイベントを集約のイベントリストに追加するだけですか？

11 domain-driven-design  repository  cqrs  event-sourcing 

本質的に非常にモジュール化された新しいソリューションの設計を検討しており、その設計をサポートする構造を作成して、将来の拡張、懸念の明確な分離、モジュールごとのライセンス付与などを可能にします。 Webで発見されたモジュラーアプリケーションまたは複合アプリケーションはUI中心で、Silverlight、WPFなどに焦点を当てています。私の場合は、さまざまなUIプロジェクトに取り組んでいる他の開発者が使用するWCFサービスアプリケーションを開発しています。 バックグラウンド 私のプロジェクトの目標は、ビジネス/ドメインロジックの一元化されたソースを作成して、現在プロセスやルールなどを複製しているいくつかのビジネスアプリケーションをサポートすることです。また、モジュール性のすべての利点が得られるわけではありませんが、活用できるこれらの部分を活用するフレームワークを確立する機会。 サービスアプリケーションによって公開されるAPIを見て、設計を開始しました。私が検討していたモジュラー回線に沿ってサービスを分離できることは明らかです。たとえば、FinanceService、InventoryService、PersonnelServiceなどのサービスを使用して、サービス操作をグループ化して、APIで高い凝集度を提供し、カップリングを低く抑えて、クライアントがアプリケーションに関連するサービスのみを消費するようにします。 MyApp.Finance、MyApp.Inventory、My.Personnelなど、これらのサービスごとに個別のモジュールを持つことができるのは理にかなっています。横断的関心事と共有タイプは、MyApp共有アセンブリにあります。ここから少し縛られます。 （ああ、アプリケーションの疎結合を維持するためにDependency InjectionにIoCコンテナーを使用することに言及する必要があります。Pandoraのボックスを開きたくないので、どれに言及しません！） MyApp.ServiceHostで、FinanceService.svcなどの各モジュールに対応するサービスホストファイル（.svc）を作成します。サービスホストには、サービスコントラクトを定義するインターフェイスを含む構成ファイルの情報に対応するサービスの名前が必要です。次に、IoC構成を使用して、使用するインターフェイスの具体的な実装をマップします。 1.サービス層はAPIを実装し、モジュールに委任する必要がありますか、またはモジュールは自己完結型である必要があります（サービス実装を含む、そのモジュールに関連するすべてを含むという点で）。 問題にアプローチする1つの方法は、サービスコントラクトの実装を含むMyApp.Services "モジュール"を持つことです。各サービスクラスは、操作のドメインロジックを含む適切なモジュール内の別のクラスに単純に委任します。たとえば、MyApp.ServicesのFinanceService WCFクラスは、Financeモジュールに実装されて操作を実行する別のインターフェイスに委任します。これにより、シンサービスファサードを維持し、実装をサービス実装に「プラグイン」して、たとえばモジュールがWCFを心配する必要がなくなります。 一方で、インターフェイスと実装を備えているという点で、各モジュールが自己完結していることが望ましい場合があります。サービスホストは、モジュールにあるサービスコントラクトインターフェイスを参照し、モジュールからの適切な実装も使用するようにIoCが構成されます。つまり、新しい.svcファイルとIoC構成情報を追加する以外に、サービスレイヤーを変更せずに新しいモジュールを追加できます。 標準のWCFからRESTfulサービスインターフェイスに切り替えるか、RIAサービスなどにアクセスした場合の影響について考えています。各モジュールにサービスコントラクトの実装が含まれている場合、サービステクノロジーまたはアプローチを変更すると、すべてのモジュールに変更を加える必要があります。しかし、ファサードが独自のモジュールである場合、変更するためにその部分を交換するだけです。モジュールは、共有アセンブリで定義されている可能性のある異なるコントラクト（インターフェイス）のセットを実装する必要がありますか？ 2.モジュール間でリソースを共有したり、モジュール間で依存関係を処理する最良の方法は何ですか？ たとえば、受信操作を考えます。商品を受け取ることは在庫機能であるため、最初は赤面でこれが在庫モジュールに入ることは理にかなっています。ただし、領収書を生成して支払いを承認する必要があるという点で、財務的な側面もあります。 一方では、操作を伝えるために何らかのタイプのドメインイベント/メッセージングを使用することを期待します。Inventoryモジュールは、Financialモジュールによって処理されるGoodsReceivedEventを発生させて、領収書を生成し、支払いプロセスを開始します。ただし、これは、金融モジュールが受け取った在庫品目について知る必要があることを意味します。IDで単純に参照できますが、名前や説明、単価など、領収書の追加情報が必要な場合はどうすればよいですか？各モジュールが、そのモジュールのニーズに合うように設計されたインベントリアイテムの独自のバージョンを持つことは理にかなっていますか？その場合、GoodsReceivedEventを処理するときに、Financialモジュールは在庫アイテムの独自のルックアップを実行する必要があります。 ... さまざまなERPシステムで多くの作業をしており、このタイプのモジュール方式で設計されていることを知っているため、この例を意図的に使用しました-方法がわかりません。また、上記では明示的に言及していませんが、ドメインドリブンデザインの原則に従ってソリューションを設計し、このタイプのモジュール性がその領域にぴったりと収まると考えています。 私の頭をこれに巻き付ける助けは大歓迎です。

11 architecture  domain-driven-design  wcf  soa  modules 

私はDDDを学んでいて、特定の状況で例外をスローすることを考えています。私はオブジェクトが悪い状態に入ることができないことを理解しているので、ここで例外は問題ありませんが、多くの例では、たとえば、データベースに電子メールが存在する新しいユーザーを追加しようとした場合にも例外がスローされます。 public function doIt(UserData $userData) { $user = $this->userRepository->byEmail($userData->email()); if ($user) { throw new UserAlreadyExistsException(); } $this->userRepository->add( new User( $userData->email(), $userData->password() ) ); } したがって、この電子メールを持つユーザーが存在する場合、アプリケーションサービスで例外をキャッチできますが、try-catchブロックを使用してアプリケーションの操作を制御するべきではありません。 これに最適な方法は何ですか？

11 object-oriented  php  programming-practices  domain-driven-design 

質問の短い形式 エンティティメソッドの呼び出しにサービスを注入することは、DDDおよびOOPのベストプラクティスの範囲内ですか？ 長い形式の例 DDDに従来のOrder-LineItemsケースがあるとします。ここでは、Orderと呼ばれるドメインエンティティがあり、これは集約ルートとしても機能し、そのエンティティは値オブジェクトだけでなく、ラインアイテムのコレクションからも構成されます。エンティティ。 アプリケーションで流暢な構文を使用して、次のようなことができると仮定します（getLineItemsメソッドを呼び出す2行目の構文に注目してください）。 $order = $orderService->getOrderByID($orderID); foreach($order->getLineItems($orderService) as $lineItem) { ... } OrderEntityにLineItemRepositoryを挿入したくないのは、それが考えられるいくつかの原則に違反しているためです。しかし、構文の流暢さは私たちが本当に望んでいるものです。それは、テストだけでなく、読みやすく、保守しやすいからです。 のメソッドgetLineItemsに注意して、次のコードを検討してくださいOrderEntity。 interface IOrderService { public function getOrderByID($orderID) : OrderEntity; public function getLineItems(OrderEntity $orderEntity) : LineItemCollection; } class OrderService implements IOrderService { private $orderRepository; private $lineItemRepository; public function __construct(IOrderRepository $orderRepository, ILineItemRepository $lineItemRepository) { $this->orderRepository = $orderRepository; …

11 object-oriented  php  domain-driven-design  domain-model  lazy-initialization