1

ドメイン駆動設計に関するいくつかの興味深い本を読むと、そのサンプルの 1 つが次のようになります。

// Order
IOrderNumberService orderNumberService;
public void Accept()
{
    this.orderNumber = this.orderNumberService.GetNextAvailableNumber();
}

上記のコードに表示されていないのは、 がOrderNumberServiceIoC フレームワークによって挿入されたことです。サービス オブジェクトのライフタイム スコープはわかりません (注入のたびに新しいサービスが作成されるか、毎回注入されるシングルトンが作成される可能性があります)。

データベースから次に使用可能な番号をチェックすることを仕事とするサービスの場合、状態は不要であり、Singleton を安全に (おそらく使用する必要があります) 使用できます。

この場合、このサービスを交換する必要はないと思います。シングルトン クラスの具体的な実装を直接簡単に呼び出すことができますOrderNumberService.GetNextAvailableNumber()。少なくとも、インターフェイスで抽象化する必要がある場合は、後でいつでもリファクタリングできます。

実装からサービス インターフェイスを抽象化してテストを容易にする以外に、サービスを注入する利点はありますか?

私は、自分が読んだすべてのものを単にクールだからという理由だけでコードに入れることに慎重です。では、どの時点で抽象化によって非常に多くのレイヤーが作成され、コードが読みにくくなり、注意すべき警告サインは何ですか?

4

2 に答える 2

3

サービスは、DDD では状態を持ちません (Evans p. 107)。サービスがどの層に属しているかは関係ありません。

ドメイン内の重要なプロセスまたは変換が ENTITY または VALUE OBJECT の自然な責任ではない場合、サービスとして宣言されたスタンドアロン インターフェイスとしてモデルに操作を追加します。モデルの言語に関してインターフェイスを定義し、操作名が UBIQUITOUS LANGUAGE の一部であることを確認します。サービスをステートレスにする

実装 (クラス) の代わりに高レベルの抽象化 (インターフェイス) を使用することは、依存関係の逆転の原則であり、依存関係の挿入ではありません。何らかの方法で初期化する必要があるインターフェイスです。つまり、クラス インスタンスに値を割り当てます。

サービス インスタンスを注入するためのテクノロジに関しては、DDD はテクノロジに依存しません。IoC コンテナーを使用すると読みにくくなると思われる場合は、代わりに Service Locator パターンの使用を検討してください。完全な理由については、DI コンテナーに関する Martin J Fowler の記事を参照してください。しかし、DDD には洗練されたチームが必要なので (Evans が infoq のいくつかの講演で言及しました)、IoC の概念を理解できるのは人だと思います。 IC フレームワークが重すぎるソリューションである Android スマートフォンなどの一部の制限された環境）

悪名高いシングルトン パターン (静的クラス メソッドで実装) については、テストできないため、まったく適していないと思います。

また、DDD は軽量フレームワークの使用を促進し (Architectural Frameworks、Evans p. 74 を参照)、最新のフレームワーク (Spring、Fluent NHibernate など) はこれを念頭に置いて開発されているため、実際には POJO/POCO での作業をより簡単にするように設計されています ( Fluent NHibernate アーキテクト Jeremy Miller によって書かれたフレームワーク設計に関する一連の記事で詳細を読むことができますhttp://codebetter.com/jeremymiller/2010/01/11/patterns-in-practice-a-retrospective/ )、多くのたとえば、Spring プロジェクトは DDD を直接参照します。したがって、フレームワークがコードに依存関係を強制したり、コードを読みにくくしたりすることはほとんどありません。代わりに、リフレクション API を使用して値を設定し、XML や属性 (注釈) などの非侵入型アプローチを使用します。構成。

于 2013-01-26T19:21:36.700 に答える
2

実装からサービス インターフェイスを抽象化してテストを容易にする以外に、サービスを注入する利点はありますか?

依存性注入は、管理が容易な構成を介して要素を結び付けます。ご指摘のとおり、1 つのユース ケースは、モック サービスを使用してコンポーネントをテストすることです。一般に、このサービス実装のさまざまなバリエーションが将来出現する可能性があり、多くの場所でコードをリファクタリングするよりも、構成を介してそれらを切り替える方が簡単になります。

最初はおそらく変更されない些細な実装のようにOrderNumberService.GetNextAvailableNumber()見えるかもしれませんが、理論的には要件が将来変更される可能性は依然としてあります。

この状況を想像してみてください。あなたのシステムを使用している顧客が他のビジネスを買収し、そこにあなたのシステムの別のインスタンスをインストールすることを望んでいます。しかし、彼らの経理部門は、単に ID を増やすのではなく、注文に番号を付ける際に何らかの日付ベースのパターンを使用しています。DI を使用すると、コードをリファクタリングすることなく、2 つのインスタンスで異なる構成を実行できます。

于 2013-01-27T01:53:00.323 に答える