アプリケーションロジック– 2つの定義のうちどちらが正しいですか？
これはApplication Layerについての私の理解です：
•Application logicを実装します
•この層にはApplication Servicesが含まれ、外部のコンシューマーがアプリケーションと通信するために使用されます
•Application Servicesは、use Casesに直接マップする粗粒度のオーケストレーション操作です（したがって、Workflow Servicesという用語も）
1）
From：
アプリケーションロジックは主にワークフローロジックです。これは、特定のアプリケーションの要件に応じた、ドメインおよびインフラストラクチャコンポーネントのアプリケーション固有の調整です。
会社を始めましょうか。 Sapient Greyは主にシンクタンクになりますが、コア委員会のビジョンを現実にする能力を持つ社内開発グループがいます。企業理念「Sapient Grey is People ...」は、ロダンの有名な彫刻「The Thinker」のカスタマイズされたバージョンとともに巨大な真ちゅうの文字で磨かれます。これらはすべて、新しい10階建ての赤の東向きの側面を飾ります。花崗岩のオフィスビル。まだオフィスビルはありません。では、オフィスビルを設計する建築家を雇います。中央に専用エレベーターと精巧な禅風のアトリウムまたは中庭を必ず含めてください。その間、建物の設計と建設が行われている間、あなたと私と私たちの他のエリートの同僚がタヒチに飛んでサピエントグレイのビジョン、目標、アジェンダをブレインストーミングし、詳細なビジネス計画を立てます。
私たちの建築家は、オフィスビルディングの詳細な青写真を作成しています。配管をどのようにレイアウトする必要があるか、電気システムをどのように分離して結び付けるか、オフィス間通信システムをどのように編成するか、およびセキュリティをどのように実装するかを理解しています。すべてのレベル。私たちの建築家が扱っているシステムと設計は、Webアプリケーション内の「アプリケーションロジック」とまったく同じです。セキュリティの実装方法、状態と永続性の管理とアクセスの方法、データの格納と取得の処理方法...これはアプリケーションロジックです。完成するとエリートナイトクラブから投資会社まで何でも収容および収容できるオフィスビルのように、アプリケーションロジックはその中で実行される実際のビジネスロジックとは無関係です。
a）上記の引用はApplication Logicという用語の2つの異なる定義であり、そのため、たまたま同じ用語を使用しているように見えます（つまり、Application logic） 2つの異なる概念を説明します。したがって、最初の定義のみがApplication layerに含まれるロジックを記述しているのに対し、後者の定義は別の種類のロジックを記述していますか？
b）実際に両方の定義がApplication layerのロジックを記述している場合、これはApplication layerが2つのタスクを実行することを意味しないでしょう：に直接マップする操作のオーケストレーション使用例およびビジネスに関連しないロジック（セキュリティ、キャッシュなど）を実行していますか？
私が最初の引用で記事を投稿したのは私であり、アプリケーションロジックのその「定義」がはっきりしていなかったことを認めなければなりません。私が「ほぼ」と言ったとき、私は間違いなく「時々」と言ったはずです。
アプリケーションロジック（うまくいけば、アプリケーションレイヤーに集中し、BBOM全体に分散しない）は、特定のアプリケーションに固有のロジックです。これは、ターゲットと再利用性の点でドメインロジックやインフラストラクチャロジックとは根本的に異なります。ドメインロジックは、対象ドメインの問題を解決するロジックであり、同じドメインコンテキストを扱うが異なる機能を公開するアプリケーションで完全に再利用可能である必要があります。インフラストラクチャロジックは、anyドメインのanyアプリケーションで再利用できる一般的な技術機能に関するものです。
とは言っても、アプリケーションロジックは、機能指向の粗粒度インターフェイスを公開するいくつかのサービスに完全に集中できますロジックがかなり単純な場合（Fowlerのトランザクションスクリプトパターンに似ていますが、このパターンのターゲットはドメインロジックの編成です。アプリケーションロジックにも拡張できます）。
一方、アプリケーションロジックがかなり複雑な場合（複雑な動的ウィザードスタイルのフローや、さまざまなユーザーロールに割り当てられた権限の複雑な組み合わせのドメインロジックとデータ関数の特定のサブセットへのユーザーアクセスを制限する必要がある場合） ）アプリケーション固有の概念のオブジェクトモデルを構築する価値があります。このオブジェクトモデルは、機能指向の大まかなファサード（論理サービス）の背後に配置できますが、アプリケーションロジックは、機能指向のサービスによって提供されるオーケストレーションだけではなく、その背後にあるオブジェクトモデルの動作でもあります。