すぐにパブリック API (Web API) を実装する必要があります。要求の 1 つは、同じことを行うために別のメソッド (たとえば、REST と SOAP) を提供する必要があるということです。私の最初のアプローチは次のとおりです。
REST のコントローラーを作成する SOAP のコントローラーを作成する
REST および SOAP インターフェイスからの要求を処理する共通の Facade クラスを使用します。Facade クラスは、システムの内部へのアクセスを担当します (直接的または間接的に、dome DAO を使用できます...など)。
コードは Java で記述され、他の技術の中でも Spring-MVC を使用する可能性が最も高いでしょう。
ここで質問です。これはあなたにとって意味がありますか？あまりにもばかげていますか？ここでオーバーアーキテクチャを感じますか？提案/経験/ベストプラクティスはありますか?
御時間ありがとうございます ：）
これはあなたにとって意味がありますか？
はい。
あまりにもばかげていますか？
いいえ。
ここでオーバーアーキテクチャを感じますか？
いいえ。
提案/経験/ベストプラクティスはありますか?
何をしているかを説明する設計パターンを見つけることができます。たとえば、GoF アダプター パターンは次のように述べています。RESTとSOAPの2つのインターフェースに特化した（アダプター）App Controller（adaptee）があります。
あなたのアプローチは私には理にかなっています。Spring MVC は単独で REST エンドポイントを処理し、XML や JSON を受け入れて返すことができます。SOAP の場合、 Spring-WSやApache CXFなどの追加のフレームワークが必要になります。
MVC パターンを使用する場合は、コントローラーに注入された他の Bean に実際の作業を委譲することにより、コントローラーをできるだけ小さく保つことが常に最善です。これらの他の Bean は、多くの場合、サービスまたはリポジトリのステレオタイプに従います (ドメイン駆動設計の用語を使用)。これらの Service および Repository Bean は、REST および SOAP エンドポイント全体で再利用できます。これがあなたの 3 番目のパラグラフの意味だと思います。もしそうなら、あなたは正しい道を進んでいます。