3

私は最近、Scott Miller と Nick Tune による Domain-Driven Design の Patterns, Principles and Practices という本を手に入れました。C# での素晴らしい例がいくつかあるので、以前に読んだ Java で書かれた他の DDD の本とは少し異なります。Domain イベントの実装は、デリゲートとイベントに対する C# のサポートにより、非常にすっきりしています。

ただし、本書のアプリケーション サービスの章で「手続き型で薄い」べきだと述べられているように、気になることが 1 つあります。アプリケーション層が薄いことを意図していることは理解していますが、なぜプロシージャルなスタイルなのでしょうか? 手続き型のコードを書きたくない、または最初から DDD を選択しなかった。また、このスタックオーバーフローの記事では、アプリケーション サービスは手続き型コードであるとラベル付けされていることもわかりました。

https://softwareengineering.stackexchange.com/questions/279369/conceptual-mismatch-between-ddd-application-services-and-rest-api

ご覧のように？アプリケーション サービスは手続き型であり、OOP ではありません。これは、アプリケーション サービスの手続き型インターフェイスを OO インターフェイスに置き換えることで、設計をよりオブジェクト指向に改善できるかどうか疑問に思います。この記事では、メソッド オブジェクトを使用することを提案していますが、それは機能しますか? 手続き型アプリケーション サービスに代わるオブジェクト指向の代替手段は何ですか? 誰でも詳しく説明できますか？

http://ayende.com/blog/2145/entities-services-and-what-goes-between-them

4

2 に答える 2

8

アプリケーション サービスは、用語のプログラミング パラダイムの意味では手続き型ではありません。これは、データ (コラボレーター オブジェクトへの参照) と動作をカプセル化するオブジェクトであり、これらのコラボレーターへの呼び出しを調整します。

一連のアクションがあるため、精神的に手続き型に見えるかもしれませんが、次のような多くのステップを意味する適用可能なタスクがある場合:

  • リポジトリからドメイン オブジェクトを取得する
  • そのオブジェクトのメソッドを呼び出す
  • オブジェクトを保存する

プログラミング パラダイムに関係なく、その手続き型/順次型の性質から逃れることはできません。

たとえば、オブジェクト指向のチェーン オブ 責任パターンを使用している場合でも、チェーン内の個別のアクターによって各ステップが実行される場合でも、チェーンを適切に組み立てる方法を知っている「マスター」オブジェクトが必要です。したがって、定義により手順を知っているため、同様に手順的です。

于 2015-10-17T17:41:17.570 に答える
1

オブジェクト指向の世界のすべてのメソッドは手続き型です:)

著者が伝えようとしているのは、アプリケーション サービスが操作スクリプトとして実装されていることだと思います。したがって、ドメインとその他のさまざまなインフラストラクチャを一連の呼び出しとして調整するだけです。理想的には、トランザクション境界もアプリケーション サービス層で処理されます。

おそらく、 Martin Fowler のサービス層に関する記事で、より多くの情報が得られるでしょう。

構造化プログラミングと手続き型コードを混同しているかもしれません:)

于 2015-10-17T09:11:13.197 に答える