問題タブ [ddd-service]

ドメイン駆動設計に従う場合、実際にサービス クラスを実装するための最良の方法は何ですか?

たとえば、AccountServiceあるアカウントから別のアカウントに資金を転送するために使用できる が必要だとしますか? 次のうち、これを実装するための最良の方法はどれですか?

私はいくつかの DDD を試しています。私が行ったことを最も簡単な方法で説明しようと思います。

コア プロジェクト
コア プロジェクトには、エンティティ、VO、およびドメイン サービスが含まれます。たとえば、UserエンティティとUserRelationエンティティがあります。Userエンティティとは何かは誰もが知っていると思います。UserRelationには、フォローや接続 (双方向フォロー) など、ユーザーが互いにどのように接続されているかに関する情報が含まれています。そのため、Follow(user,user) や Connect(user, user) などのステートレス メソッドを備えたUserDomainServiceがあります。

リポジトリ プロジェクト

私はNHibernateを使用しているので、そのようなプロジェクトを作成しないことにしました。代わりに、NHibernate を直接使用しています。たとえば、私の UI では、DB からユーザー オブジェクトを取得し、それを変更してから、session.Save(user) を呼び出します。

問題

次のような操作を行いたい場合は、次のようにします。

• DBから情報を取得する
• サービスから Follow(user1, user2) を呼び出します
• UserRelation オブジェクトを DB に保存 最終的に、アプリケーション コードは少し複雑になります。このコードを 2 ～ 3 か所で使用し、ある時点でリファクタリングする必要があるとします。

私の解決策
私の解決策は、汚い仕事をして消費者にエンティティとドメインサービスを直接使用する代わりにApplicationServiceを使用させるApplicationServiceプロジェクトを作成することです

このアプリケーション サービスは良いですか、それとも悪いですか。ご覧のとおり、新しいサービスはリポジトリとしても機能するため、UserRepository クラスを作成できますが、ここでは省略します。気になるのは、2 つのメソッドのパラメーターです。それらは Guid を受け入れ、サービスは DB からユーザーを取得します。もう 1 つのオプションは、User オブジェクトを直接渡すことです。ChangeUsername メソッドは、User エンティティ + 永続性のものと似ています。

さて、これについてどう思いますか？

Zone私はオブジェクトのツリーを持っています:

ドメイン モデルでこれらの関係を管理する手間を省きたいので、Zone にはプロパティもプロパティもありません。 childrendescendants

代わりに、ドメイン サービスは、データベース内にクロージャ テーブルを保持し、任意のレベルでゾーンをそのすべての子孫にマップします。

これで、User1 つまたは複数のゾーンを割り当てることができる があります。

私の問題は、新しいゾーンをユーザーに割り当てる前に、このゾーンがまだ割り当てられていないことを、その子孫のいずれかを介して明示的または暗黙的に確認したいということです。

したがって、必要なチェックを実行するために、コントローラーで Service をこのメソッドに一時的に挿入する必要があります。

それは良い習慣ですか、そうでない場合、正しい代替手段は何ですか?

私は予約クラスを持つドメインモデルで作業しています:

このchangeStatus()メソッドは、すべての適切な通知 (電子メールなど) が送信されるコンテキストでのみ呼び出す必要があるため、このメソッドの呼び出しを次のように制限したいと思いますReservationService。

私は PHP を使用しているため、パッケージの可視性やフレンド クラスなどの概念はありません。そのため、私のchangeStatus()メソッドは単にパブリックであるため、アプリケーションのどこからでも呼び出すことができます。

この問題に対して私が見つけた唯一の解決策は、ある種の二重ディスパッチを使用することです:

潜在的な欠点は次のとおりです。

• それは設計を少し複雑にします
• それはエンティティにサービスを認識させますが、それが実際に欠点であるかどうかはわかりません

上記のソリューションについて何かコメントはありますか、またはこのchangeStatus()メソッドへのアクセスを制限するために提案するより良い設計はありますか?

私はタマネギの建築を数日間研究しています。依存性は常に中心に向かうべきであり、これを達成するために依存性注入を使用する方法を理解しています。しかし、まだ理解できない質問がいくつかあります。

1. モデル（またはエンティティ）はリポジトリインターフェイスまたはサービスインターフェイスを参照できますか？

   例：Orderエンティティには、外部キーではありませんが一意であるプロパティDeliveryCityを通じて確立された関係があります。市をzipで取得するには、電話する必要がありますOder.DeliveryZipICityRepository.FindByZip(zip)

   モデルに次のコードがあります

   /li>

2. 上記のコードの問題は何でしょうか？代わりにドメインサービスを使用する必要がありますか？

3. ドメインサービスの実装は、コア内で定義する必要がありますか、それともインフラストラクチャ層で定義する必要がありますか？

Evans、Nilsson、McCarthy などを読み、ドメイン駆動設計の背後にある概念と理由を理解しています。ただし、これらすべてを実際のアプリケーションにまとめるのは難しいと感じています。完全な例がないため、頭を悩ませています。多くのフレームワークと簡単な例を見つけましたが、これまでのところ、DDD に従って実際のビジネス アプリケーションを構築する方法を実際に示したものはありません。

一般的な注文管理システムを例に、注文キャンセルの場合を考えてみましょう。私のデザインでは、注文番号と理由をパラメーターとして受け入れる CancelOrder メソッドを持つ OrderCancellationService を見ることができます。次に、次の「手順」を実行する必要があります。

1. 現在のユーザーが注文をキャンセルするために必要な権限を持っていることを確認します
2. OrderRepository から、指定された注文番号の Order エンティティを取得します
3. 注文がキャンセルされる可能性があることを確認します (サービスは注文の状態を調べてルールを評価する必要がありますか? または、注文にルールをカプセル化する CanCancel プロパティが必要ですか?)
4. Order.Cancel(reason) を呼び出して、Order エンティティの状態を更新します。
5. 更新された注文をデータ ストアに保持する
6. CreditCardService に連絡して、処理済みのクレジット カード請求を元に戻す
7. 操作の監査エントリを追加します

もちろん、これはすべてトランザクション内で発生する必要があり、どの操作も独立して発生することは許可されません。つまり、注文をキャンセルした場合、クレジット カード取引を元に戻す必要があります。キャンセルすることはできず、この手順を実行しません。これは、imo、より良いカプセル化を示唆していますが、ドメイン オブジェクト (Order) の CreditCardService に依存したくないので、これはドメイン サービスの責任のようです。

これをどのように「組み立てる」ことができるか/すべきかのコード例を見せてくれる人を探しています。コードの背後にある思考プロセスは、すべての点を自分で結び付けるのに役立ちます。どうも！

DDD では、エンティティまたは値オブジェクトではないクラスはすべてサービスにする必要がありますか?

たとえば、ライブラリでは、いくつかのクラスに名前が付けられFileReaderています (File オブジェクトを読み取ります)、またはCacheによって実装されるインターフェイス、XXXManager、...MemcachedCacheFileCache

DDDの外では、好きなようにクラスに名前を付けることができます。

しかし、DDD (および同じ例) では、自分のクラスに、、、によって実装された、などの名前を付ける必要がFileReadingServiceありCacheServiceますFileCacheServiceかXXXService?

DDDのファクトリ、リポジトリ、およびサービスに関していくつか質問があります。次のエンティティがあります: フォルダー、ファイル、FileData。

私の意見では、「フォルダ」は集約ルートであり、File および FileData オブジェクトの作成を担当する必要があります。

したがって、私の最初の質問は、ファクトリを使用してこの集計を作成する必要があるか、それともリポジトリ次第ですか? 現時点では、フォルダー用とファイル用の 2 つのリポジトリがありますが、それらをマージする必要があるようです。次のコード スニペットは、インフラストラクチャ レイヤーにあるフォルダー リポジトリを示しています。

次に、アプリケーション層にサービスを作成しました。これは「IoService」と呼ばれます。サービスの場所について疑問があります。ドメイン層に移動する必要がありますか?

要約すると、フォルダー オブジェクトの作成にサービスを使用する必要があります。それとも、サービスは、オブジェクトを作成し、作成されたオブジェクトをリポジトリに送信する責任を持つファクトリを使用する必要がありますか? サービスの依存性注入についてはどうですか? Unityのような IOC コンテナーを使用して UI レイヤーからサービスを注入する必要がありますか、それともサービスの依存性をハードコードするだけですか?

ありがとう

「債券」を処理する金融アプリケーションがあります。する必要がある

1. 貧血モデルを回避するためにアプリケーションをモデル化します (これは悪いことだと理解しています)。
2. 結合のタイプに応じて、さまざまな実装をインスタンス化します。

システムは外部システムから命令を取得し、その命令を指定された結合に適用します。したがって、私は命令エンティティを持っています

例えば、債券で可決された決議に「賛成」票を投じる指示の場合

および債券エンティティ

ただし、命令は通常、1 つ以上のことを行います (事実上、1 つの命令で多数の命令になります)。たとえば、前の命令をキャンセルする命令は、まず前のトランザクションをキャンセルし、次に特定の値を再計算する必要があることを意味します。また、単一の命令が過負荷になる可能性があります。これは、以前の命令をキャンセルしたり、解決策を投票したりするためです。

ドメイン サービスを使用して新しい命令を処理するように勧められました。

この構造で見られる問題は、メソッドが関連していなくても、命令ごとにすべてのメソッドが呼び出されることです。if ステートメントを使用することもできますが、コードが乱雑に見えます。

今、私の質問は、

1. これはモデル化するための最良の方法ですか？
2. また、計算については、債券の種類によって計算が異なります。だから私はポリモーフィズムを実装したい。ファクトリを使用して正しい実装をインスタンス化する必要があると言われました。これは最善のアプローチですか？

BondType 1,3,5 の場合、計算 A を使用し、bondType 2,7 の場合...計算 B を使用する必要があります。異なる計算タイプをインスタンス化するにはどうすればよいですか??? NB、私はポリモーフィズムに精通していますが、正しい実装をインスタンス化する方法の確かな例を見つけることができませんでした。ここまで読んでくれてthnx…

ドメイン駆動設計では、ドメイン サービスには、本来はエンティティ内に属さない操作を含める必要があります。

エンティティごとに 1 つのサービスを作成し、その中にいくつかのメソッド (OrganizationエンティティとOrganizationServiceサービス)をグループ化する習慣がありました。

しかし、考えれば考えるほどOrganizationService、「組織」はサービスではなく、物です。

そのため、現在、組織全体を複製する組織のディープ コピー機能を追加する必要があるため、それをサービスに入れたいと考えています。

すべきこと: OrganizationService::copyOrganization(o)?

または、次のことを行う必要がありますOrganizationCopyService::copyOrganization(o)。

より一般的には、「サービス」はいくつかの操作を含む抽象的な概念ですか、それともサービスは具体的な操作ですか?

編集：最初のものはそれほど良くなかったので、より多くの例：

• StrategyService::apply()/cancel()またはStrategyApplicationService::apply()/cancel()？(ここでの「アプリケーション」はアプリケーション層とは関係ありません;)
• CarService::wash()またはCarWashingService::wash()？

これらすべての例で、最も具体的なサービス名が最も適切と思われます。やはり、実生活では「洗車サー​​ビス」というのは理にかなっています。でも、サービスがいっぱいになってしまうかも…。

※注：これは意見を求める質問ではありません！これは、ドメイン駆動設計の方法論に関する正確で回答可能な質問です。「私はすべきか」と尋ねるとき、私はいつも僅差の投票にうんざりしていますが、物事を行うための DDD の方法があります。