3層（DAL、BL、UI）でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。
同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。
個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。
このアプリには、デスクトップアプリケーションの機能の一部（ただしごくわずか）を使用する小さな部分UIが追加されているため、コードを（あまり多くは）複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。
私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。
回答:
マーティンファウラーの著書「Patterns of Enterprise Architecture」は次のように述べています。
答えが簡単な質問は、おそらくそれを使用しない場合です。アプリケーションのビジネスロジックが1種類のクライアント（たとえば、ユーザーインターフェイス）のみを持ち、ユースケースの応答に複数のトランザクションリソースが含まれない場合、おそらくサービスレイヤーは必要ありません。[...]
しかし、2番目の種類のクライアント、またはユースケースの応答で2番目のトランザクションリソースを想定するとすぐに、最初からサービスレイヤーでの設計に費用がかかります。
サービス層が提供する利点は、さまざまなクライアントが利用できるアプリケーション操作の共通セットを定義し、各操作で応答を調整することです。ビジネスロジックを消費する複数の種類のクライアントがあり、複数のトランザクションリソースが関係する複雑なユースケースを持つアプリケーションがある場合、マネージドトランザクションにサービスレイヤーを含めることは理にかなっています。
CRM、セールス、インベントリには、CRUDタイプのユースケースが多数あり、そのほとんどの場合、サービスレイヤーのオペレーションと1対1の対応があります。ドメインオブジェクトの作成、更新、または削除に対する応答は、サービスレイヤーの操作によって原子的に調整および処理される必要があります。
サービスレイヤーを持つことのもう1つの利点は、ローカルまたはリモートの呼び出し、またはその両方のために設計できることです。また、そのための柔軟性を提供します。このパターンは、アプリケーションのビジネスロジックのカプセル化された実装と、さまざまなクライアントによる一貫した方法でのそのロジックの呼び出しの基盤となります。これは、クライアントが同じ共通サービスを共有するため、コードの重複も削減/削除することを意味します。ビジネスロジックが変更された場合、（通常）サービスを変更するだけで、各クライアントではなく、メンテナンスコストを削減できる可能性があります。
要約すると、サービスレイヤーを使用するのは良いことです。さらに、ビジネスロジックの複数のクライアントがあるように聞こえるので、あなたの例で提供したと思います。
With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations-それがすべて複数のUIである場合、CRUDはどのようにここに入りますか？そして、CRUDがサービスとうまくいっていても複数のUIを必要としないなら、私が正しく理解していれば、私はまだサービスレイヤーを作成しません。私の経験の浅い意見に混乱）
あなたのアイデアを評価し、その最善のアプローチを締結しているため、サービスレイヤの追加：良いです
：それはすべてのクールな子供たちがやっていることだからサービス層を追加する悪いです
あなたの腸があなたがそれを必要としないと言ったら、それを作らないでください。
過去10年ほどでプログラミングの世界で最も残念な開発の1つは、人々が今シーズンの靴のようにトレンドや時流に追随するという、いらいらする「ファッション」指向になったことです。そのtrapに陥らないでください。来シーズン、「誰もが」あなたがそれを他の方法で設計すべきだったとあなたに告げるからです。
サービス層には何の問題も正しいものもありません。それは、手元のプロジェクトの技術的メリットでその適合性を評価する必要がある特定のアプローチです。自分の判断を他の人の意見に置き換えることを余儀なくされてはいけません。
サービスレイヤーの作成を決定する要因は多数あります。次の理由で、過去にサービスレイヤーを作成しました。
ケース1：無数のさまざまなクライアントが使用する必要がある基本機能を作成しています。サービスレイヤーは、さまざまなクライアントがすぐに提供された機能を利用できる機能を組み込みます。
ケース2：通常、アプリスペースでコードをホストしていますが、ライセンスが制限されているサードパーティのライブラリを使用しています。この場合、どこでも使用したいリソースがありますが、限られた数だけです。サービスの背後でホストする場合、組織全体が各ホスティングのライセンスを購入することなく、アプリケーションから使用できるようになります。
ケース3：サードパーティが通信するための機能を構築しています。この例では、在庫エンドポイントを設定して、ベンダーが製品の入荷に関するメッセージを渡すことができるようにすることができます。
ケース4：エンタープライズ全体でコードを分析し、別々のチームが同じものを作成していることがわかりました（わずかに異なる方法で実装されただけです）。サービスレイヤーを使用すると、最適なアプローチを選択できます。また、サービスを呼び出すことで、すべてのチームに同じプロセスを実装できます。ロジックを集中化するもう1つの利点は、バグが見つかったときです。これで、修正プログラムを1回展開するだけで、すべてのクライアントが同時にメリットを享受できます。
これはすべて、サービスレイヤーにマイナスの可能性があると言われています。
主なポイントは、システムをサービス指向にすることは必ずしもスラムダンクではないということです。私の経験では、通常は良いアイデアです（この方法でアプリケーションを構築する傾向があります）が、それは自動的な決定ではありません。結局のところ、長所と短所を比較検討し、あなたの状況に合った決定を下す必要があります。
私が見たほとんどのサービス層は完全な混乱です。サービスには多くの異なる方法がある傾向があり、1500 LOCは珍しいことではありません。異なるメソッドには共通点はありませんが、コードを共有します。これにより、結合度が高く、凝集度が低くなります。また、OCPに違反します。新しい操作が必要になるたびに、コードベースを拡張する代わりにコードを変更する必要があるためです。よく構築されたサービス層は理論的には可能ですが、実際には見たことがありません。
CQRSはこれらの問題を解決し、これらの手続き型サービスレイヤーの1つを作成する必要がないようにします。
インターフェイス（サービスレイヤーはインターフェイスの一種です）の追加には時間がかかります。良いものは、設計とテストに時間がかかります。後で変更するとすべてのクライアントが破損するため、最初の試行で正しく設定することが非常に重要です。また、わずかに異なるニーズを持つ2番目のクライアントが見つかるまで、そのインターフェイスに何が必要かはおそらくわからないと考えてください。サービスの維持は、それ自体で終わりのないプロジェクトです。
ほとんどの組織では、ビジネススポンサーに行って、「他の部門に予算で開発しているこのシステムのメリットを（再利用）してもらいたいですか？」彼らはあなたを笑います。最初にビジネススポンサーのために機能させてから、そのコードを（部署の都合に合わせて）再利用してみてください。
実際、今日書いている機能が複数の異なるサービスクライアントによって再利用されることがわかっている場合は、初日からサービスレイヤーの設計を検討してください。不明な場合、またはプロジェクトに多くの未知のものが既にある場合は、最初に単純な作業を行い、時間と予算があれば後でサービスとクライアントに分けます。稼働中のシステムで開始する場合、最初の試行でサービスインターフェイスを取得する方がはるかに簡単です。
PS Javaで作業している場合、Joshua Blochの著書「Effective Java」では、素晴らしいインターフェースのアドバイスがたくさんあります。
仰るとおりです。単一のUIを使用している場合、もう1つのレイヤーを含める必要はありません。
DAL、BL、およびUI / Controllerは、アプリケーションの設計に適した組み合わせです。単一のUIを使用する場合、追加のレイヤーを準備する必要はありません。アプリケーションにさらに1つのレイヤーを含めると、開発の労力/時間が増加するだけです。
もう1つの方法は、アプリケーションで複数のUIを使用することです。この場合、UIを処理するサービスレイヤーを用意することをお勧めします。
私はあなたのBLがあなたのサービス層であることを争います。ビジネスロジックが配置される中心的な場所。これは、そのロジックを必要とするあらゆるものが使用できるDLLでなければなりません。その後、アプリのUIが異なる場合は、その上にWeb APIレイヤーを配置できます。