c# - WCF 懸念の分離 VS DRY

Question

私は、WCF クラスを独自の「プレゼンテーション レイヤー」に分離した WCF サービス アプリケーションを作成しています (適切な用語がないため)。その下には、ドメイン オブジェクトを調整するアプリケーション層があります。

私は、WCF テクノロジがアプリケーション層に漏れていないという事実が気に入っているので、Web API のようなものに簡単に交換できます (これについては検討しました)。しかし、私の懸念は、自分自身を繰り返さないというルールに違反しているように見えることです. WCF 層は本質的に、呼び出しをアプリケーション層に渡すだけの "プロキシ" 層になり、同じ署名を維持します。

例えば：

public void Method(string arg)
{
   _appService.Method(arg);
}

これはオーバーキルですか？ロジックを WCF クラスに移動する必要がありますか?

Answer 1

サービス指向アプリケーション全体で DRY 原則を実装する場合は注意が必要です。多くの場合、サービスは独自のBounded Contextを形成し、他のサービスのビジネス ロジックとは独立してコードを進化させたい場合があります。このルールの例外は、垂直スライス全体にわたる分野横断的な問題に対処する「ユーティリティ」コードです。

あなたが与える特定の例に関して、あなたはロジックをホストされている方法から分離しました。コードのコンテキストが異なるため、これは DRY に違反しません。