ロギングロジックをビューレイヤーまたはサービスレイヤーに配置する必要がありますか？要求ログはどこに属していますか？
サービスレイヤーは複数の異なるビュー（http、rpcなど）の基礎となる共通レイヤーであるため、より意味をなさないと思っています。ビュー層でロギングが行われた場合は、ビューごとにロギングする必要があります。
しかし、すべてのロギングロジックがサービスレイヤーにある場合、ビューレベルで着信要求と失敗を記録するものはありません（JWT認証失敗など）。要求はサービスに到達する）。
ログはどこで行われるべきですか？
ロギングは複数のレイヤーで行われることを意味します（認証と同様）。したがって、たとえばからログオンする必要があると感じたら、プレゼンテーションレイヤー - 実際の実装とは独立した共通のインターフェイスを使用するだけです。たとえば、Javaでは、slf4jを使用します。これは、基になるロガー実装のファサードです。しかし、あなたは、一般に、その伐採ファサードを使用する1つの場所を持つことは良い考えです。通常、ほとんどの例外、警告などをログに記録するので、例外を処理するコンポーネントにそれらを記録します。 Springでは、多くの場合、このようなコンポーネントのタグ付けには@ControllerAdviceアノテーションが使用されます（すべてのコントローラ呼び出しをインターセプトしたり、例外を中央の場所で処理するなどのオプションがあります）。もう1つの方法は、すべてのメソッド/例外をログに記録するのに（AspectJ）AOPプログラミングを使用することです（しかし、アドバイスされたジョインポイントの実行中にログに記録するメッセージを設定することはできません）。また、イベントを使用することもできます。これは非常に洗練されたソリューションです。コードが行うすべての意味のあるイベントは、どこか別の場所で処理されるためです（たとえば、すべてのイベントを記録するコンポーネント）。
したがって、すべてのレイヤーでアップログが発生する可能性がありますが、logger.log()呼び出しをコード内に分散させず、より構造化されたアプローチ（中央例外処理クラス、aopまたはイベント）を使用する必要があります。
ところで、質問はDDDに関連しないので、ドメイン駆動型デザインタグを削除する必要があります。
DDDタグを削除しました –
なぜ両方ではないのですか？アプリケーションの構成設定によって、どのロギングを有効/無効にするかを決定できます。適切なログフレームワークには、このような設定オプションがあります。 – David
私は、ロギングロジックを1か所に集中させるという考えのようなものです。また、ロギングがゲートウェイサービスとして実装されている場合、ビューには（理想的には）その知識がなくてはなりません。ビューレイヤへのログインを開始するには、このサードパーティのログサーバーの知識が必要で、そのログサーバーとの通信方法がわかっている必要があります。 – user7467314
アプリケーション層では、その依存関係の知識はまったく必要ありません。具体的な内容はテクノロジによって異なる場合がありますが、一般的には、すべてのコンポーネントがログに記録できる、自分のドメイン内にロギングインターフェイスがあります。依存関係の逆転は、そのインタフェースの実装を提供し、インタフェースを使用する任意のコンポーネントには未知です。あなたが任意に1つの場所にしかログインしないことを望んでいれば、その場所を選ぶ必要があります。しかし、アプリケーションコードとサービスコードは非常に異なることを行い、非常に異なるデータで動作します。個人的には両方をログに記録するオプションが必要です。 – David