デカップリングはRESTのDRYに勝りますか？

既存のJava APIのほとんどの機能を公開するREST APIを構築しています。両方のAPIは、組織内で使用するためのものです。外部で使用するために設計する必要はありません。私は両方のAPIに影響を及ぼしていますが、REST APIを実装しています。Java APIは引き続きローカルアプリケーションに使用されます（「非推奨」ではありません）が、重要な新規開発にはREST APIが使用されます。

Java APIクラスの一部は単なるデータです（プロパティ、ゲッター、セッターを持つBean）。そして少なくともこれらのいくつかは、REST APIを介して（何らかの形で）データ（XMLまたはJSONにマーシャリングされる）として送信するのに意味があります。たとえば、サーバーマシンに関する情報を格納するクラス。これらのデータクラスについて、次の選択に直面しています。

1. 元のJavaクラス（またはサブクラス）をREST APIで直接公開する、または
2. REST API専用の新しいデータ転送クラス（DTOパターン）を作成しますか？

いずれにせよ、RESTデータ転送クラスがあります。問題は、オリジナルに注釈を付けるか、新しいものを作成するか（オリジナルのコピーに近い場合があります）です。他の選択肢もありますが、主にこれら2つに焦点を当てます。

＃1の引数：

• DRY（繰り返さないでください）
• 実装が速い
• REST APIのアップグレードが簡単

＃2の引数：

• REST APIをJava APIとは別にバージョン管理する必要がある場合はどうなりますか？（これは多少可能性があります。）
• プロパティの削除、動作の追加、クラス階層の変更など、Javaデータクラスに大幅な変更があった場合はどうなりますか？（これも多少可能性があります。）

要するに、DRY（＃1）とデカップリング（＃2）の間のトレードオフのように思えます。

＃1から始めて、その後＃2に移って問題が発生した場合は、必要なことを証明できないものを構築しないというアジャイルガイドラインに従っています。これは悪い考えですか。とにかくそこに行き着くかもしれないと思うなら、私は＃2から始めるべきですか？

私のリストに欠けている主要な議論/結果はありますか？

いい質問、簡単に言えば、分離。それはここに行く方法です、あなたはjavaのバージョンに縛られたくありません。

切り離さないシナリオが1つあります：テクノロジがタイプ固有でないオブジェクトをネットワーク経由で送信できるようにする場合、つまり現在のJavaオブジェクトをYAGNIとして使用でき、別のオブジェクトに置き換えることができる場合カスタマイズするタイプは、ワイヤを介してタイプ情報が送られても何も壊さないシンプルなドロップインになります。したがって、基本的に型情報がネットワークを越えない場合は、これをYAGNIできます。

Javaバージョンへのアップグレードによってこれらのオブジェクトが変更されないように注意してください。それ以外の場合は、今すぐ分離して、それについて心配しないでください。選択がある場合、どれだけの時間があるかに依存すると思います。

ただし、型情報がプロトコル内のワイヤを通過する場合、基礎となるJava型が変更されたときに新しい型のフラットドロップインが不可能になる可能性があり、かなり大きな努力になる可能性があります。その場合、YAGNIへの移行は、基礎となる技術に関連する技術的負債とリスクの発生を意味します。

個人的に私は今すぐ分離します。

また、基礎となる部分を記述しなかったためコードを複製しないため、DRYはこれに関与しません。したがって、DRYの主な関心事であるバグを繰り返し繰り返すという苦痛はありません。維持する重複がないために再び発生する問題）

＃1の主な論点は、実装とアップグレードの容易さですが、要件を満たしていますか？

＃2の引数では、Java APIとREST APIが独立して変更される可能性が高いことを示しています。これは、それらが別個の関心事であり、別個のクラスを使用することによって自分自身を繰り返さないことを意味します。2つのものが同じように見えるからといって、同じであるという意味ではありません。

REST APIは、データモデルと同じ構造に従う必要はありません。

RESTを実装するときは、直感的な外部APIを作成していることを確認してから、これを内部データモデルクラスにマッピングします。これにより、それぞれを独立して変更し、数十年続くAPIに導くことができます。

したがって、デカップリングはここに行く方法です。