サービス層を作ることはどれほど重要ですか？
私は3層（DAL、BL、UI）でアプリの構築を開始しました（主にCRM、一部の販売レポート、在庫を処理します）。
ある同僚から、私はサービスレイヤーパターンに移行する必要がある、開発者は経験からサービスパターンに来たので、ほとんどのアプリケーションを設計する方がより良いアプローチであると言われました。そうすれば、将来的にアプリケーションを保守する方がはるかに簡単になると彼は語った。
個人的には、それが物事をより複雑にするだけだと感じ、それを正当化する利点の多くを見ることができませんでした。
このアプリには、デスクトップアプリケーションの機能の一部（ごく一部のみ）を使用する小さな部分UIが追加されているため、一部のコードを複製しています（ただし、多くはありません）。コードが重複しているからといって、サービス指向に変換するつもりはありませんが、彼はとにかくそれを使用するべきだと言いました。
私はグーグルで試してみましたが、それでも混乱していて、どうすればいいのか判断できません。
マーティンファウラーの著書「エンタープライズアーキテクチャのパターン」には、
答えるのが簡単な質問は、おそらくそれを使用しないときです。アプリケーションのビジネスロジックに1種類のクライアント（ユーザーインターフェイスなど）しかなく、ユースケースの応答に複数のトランザクションリソースが含まれない場合は、サービスレイヤーはおそらく必要ありません。 [...]
しかし、2番目の種類のクライアント、またはユースケース応答の2番目のトランザクションリソースを想定するとすぐに、最初からサービスレイヤーで設計することは価値があります。
サービス層が提供する利点は、さまざまなクライアントが使用できるアプリケーション操作の共通セットを定義し、各操作での応答を調整することです。ビジネスロジックを消費する複数の種類のクライアントがあり、複数のトランザクションリソースが関与する複雑なユースケースがあるアプリケーションがある場合、マネージドトランザクションにサービスレイヤーを含めることは理にかなっています。
CRM、Sales、Inventoryでは、多くのCRUDタイプのユースケースがあり、そのほとんどの場合、サービスレイヤーオペレーションと1対1で対応します。ドメインオブジェクトの作成、更新、または削除に対する応答は、サービスレイヤー操作によってアトミックに調整および処理される必要があります。
サービスレイヤーを使用するもう1つのメリットは、サービスレイヤーをローカルまたはリモートの呼び出し、あるいはその両方のために設計できることです。これにより、柔軟性を実現できます。パターンは、アプリケーションのビジネスロジックのカプセル化された実装と、さまざまなクライアントによる一貫した方法でのそのロジックの呼び出しの基礎を築きます。これは、クライアントが同じ共通サービスを共有するため、コードの重複を削減/削除することも意味します。メンテナンスコストも削減できる可能性があります。ビジネスロジックが変更された場合、（通常は）サービスを変更するだけでよく、各クライアントを変更する必要はありません。
要約すると、サービスレイヤーを使用するのは良いことです。つまり、ビジネスロジックのクライアントが複数あるように聞こえるので、あなたの例では提供していると思います。
アイデアを評価し、その最善のアプローチを完了したため、サービスレイヤーを追加します。good
サービス層を追加するのは、それがすべてのかっこいい子供たちが行っていることだからです。bad
あなたの腸があなたがそれを必要としないと言ったら、それを作ってはいけません。
過去10年間のプログラミングの世界での最も残念な進展の1つは、今シーズンの靴であるかのように人々がトレンドや流行に追われて、迷惑なように「ファッション」志向になったことです。その罠に陥らないでください。来シーズンは「みんな」があなたに何か他の方法でそれをデザインすべきだったと言ってくるからです。
サービス層には何も問題はありません。これは、目前のプロジェクトの技術的なメリットを評価する必要がある特定のアプローチです。自分の判断を他人の意見に置き換えることを強いられないでください。
サービス層を作成するかどうかを決定する要素はたくさんあります。以下の理由により、過去にサービス層を作成しました。
- 複数のクライアントで再利用する必要があるコード。
- ライセンスが制限されているサードパーティのライブラリ。
- システムへの統合ポイントを必要とするサードパーティ。
- 複製されたビジネスロジックを一元化する。
ケース1：無数の異なるクライアントが使用する必要のある基本機能を作成しています。サービス層は、さまざまなクライアントが提供する機能をすぐに利用できるようにする機能を組み込んでいます。
ケース2：通常はアプリ空間でコードをホストしていますが、ライセンスが制限されているサードパーティライブラリを使用しています。この場合、どこでも使用したいリソースがありますが、リソースの数は限られています。サービスの背後でホスティングする場合、組織全体で、個々のホスティングのライセンスを購入しなくても、アプリケーションから使用できます。
ケース3：サードパーティがあなたと通信するための機能を構築しています。あなたの例では、仕入先が入ってくる製品の出荷についてあなたにメッセージを渡すことができるように在庫エンドポイントを設定できます。
ケース4：企業全体でコードを分析したところ、別々のチームが同じものを作成したことがわかりました（わずかに異なる方法で実装されています）。サービスレイヤーを使用すると、最適なアプローチを選択でき、サービスを呼び出すことで、すべてのチームに同じプロセスを実装できます。ロジックを一元化するもう1つの利点は、バグが見つかったときです。これで、修正を1回展開すると、すべてのクライアントが同時にメリットを享受できます。
これらすべては、サービス層に潜在的なマイナスがあると言われています。
- システムが複雑になります。以前はデバッグするアプリケーションが1つだけでしたが、現在は2つです。本番環境の問題では、クライアントアプリの設定、サービスアプリの設定、または正しく設定されていないクライアントアプリとサーバーアプリ間の通信の問題を確認する必要があります。これまでに行ったことがない場合、これは注意が必要です。
- 1つの障害点。サービスが停止している場合、すべてのクライアントが影響を受けます。この方法でコードをデプロイしない場合、リスクは少なくなります（これを軽減する方法はあります）。
- バージョン管理を行うのは難しい場合があります。サービスを使用するアプリが1つある場合、インターフェースのデプロイは2つの間で同時に行うことができます。複数のクライアントがある場合、誰がV1にいて、誰がV2にいて、V1の削除を調整する必要があります（全員がV2に更新したことがわかったら）。
重要な点は、システムサービスを指向にするのは必ずしもスラムダンクではないということです。私の経験では、それは通常は良い考えです（私はこのようにアプリケーションを構成する傾向があります）が、それは自動的な決定ではありません。結局のところ、長所と短所を比較検討し、状況に応じて適切な決定を行う必要があります。
私が見たほとんどのサービス層は完全な混乱です。サービスには多くの異なる方法がある傾向があり、1500 LOCは珍しくありません。異なる方法には共通点はありませんが、コードを共有します。その結果、高い カップリング 、低い 結合力 になります。また、これは [〜＃〜] ocp [〜＃〜] に違反します。これは、新しい操作が必要になるたびに、コードベースを拡張する代わりにコードを変更する必要があるためです。うまく構築されたサービス層は理論的には可能ですが、実際には見たことがありません。
[〜＃〜] cqrs [〜＃〜] これらの問題を解決し、これらの手続き型サービスレイヤーの1つを作成する必要がなくなります。
インターフェースの追加（サービス層はインターフェースの一種です）には時間がかかります。良いものは、設計とテストに多くの時間を費やします。後で変更するとすべてのクライアントが壊れるので、最初の試行で正しく取得することが非常に重要です。また、わずかに異なるニーズを持つ2番目のクライアントが作成されるまで、そのインターフェイスに何が必要かわからないことを考慮してください。サービスの維持は、それ自体が終わりのないプロジェクトです。
ほとんどの組織では、ビジネススポンサーのところに行き、「予算で開発しているこのシステムのメリットを他の部門に（再利用）してもらいたいですか？」彼らはあなたを笑います。まずビジネススポンサーのために機能させてから、そのコードを再利用して（部門の都合のよいときに）いじり始めます。
実際、今日作成している機能が複数の異なるサービスクライアントによって再利用されることがわかっている場合は、最初からサービスレイヤーを設計することを検討してください。確信が持てない場合、またはプロジェクトに多くの不明な点がある場合は、まず簡単な作業を行い、時間と予算がある場合は後でサービスとクライアントに分けます。稼働中のシステムから始めると、最初の試行でサービスインターフェースを正しく設定する方がはるかに簡単です。
追伸Javaで作業している場合、Joshua Blochは、彼の著書「Effective Java」を通じて、すばらしいインターフェースに関するアドバイスを数多く提供しています。
仰るとおりです。単一のUIを使用している場合は、レイヤーを1つ追加する必要はありません。
DAL、BL、UI/Controllerは、アプリケーションを設計するための良い組み合わせです。単一のUIを使用する予定の場合は、追加のレイヤーを準備する必要はありません。アプリケーションにさらに1つのレイヤーを含めると、開発の労力/時間が増えるだけです。
別のスキーマは、アプリケーションで複数のUIを使用することです。この場合、UIを処理するサービスレイヤーを用意することをお勧めします。
私はあなたのBLがあなたのサービス層であることを争います。ビジネスロジックが置かれる中心的な場所。これは、DLLである必要があります。これは、そのロジックを必要とするあらゆるもので使用できます。アプリに異なるUIがある場合は、その上にWeb APIレイヤーを配置できます。