Есть ли развязка козыря СУХОЙ в ОТДЫХЕ?

Я строю REST API, чтобы показать большую часть функциональности существующего Java API. Оба API предназначены для внутреннего использования в моей организации; Я не должен проектировать для внешнего использования. Я имею влияние на оба API, но я использую REST. Java API будет по-прежнему использоваться для локальных приложений (он не «удаляется»), но REST API будет использоваться для значительных новых разработок.

Некоторые из классов Java API - это просто данные (бины со свойствами, геттеры, сеттеры). И, по крайней мере, некоторые из них имеют смысл передавать (в некоторой форме) через REST API в виде данных (которые будут перенаправлены в XML или JSON). Например, класс, в котором хранится информация о сервере. Я столкнулся со следующим выбором для этих классов данных: я ...

1. предоставить исходный класс Java (или подкласс) непосредственно в REST API, или
2. сделать новый класс передачи данных (шаблон DTO) специально для REST API?

В любом случае у меня будут классы передачи данных REST; вопрос заключается в том, нужно ли комментировать оригиналы или создавать новые (которые могут быть рядом с копиями оригиналов). Могут быть и другие варианты, но я сосредоточусь в основном на этих двух.

Аргументы за № 1:

• СУХОЙ (не повторяйся)
• Быстрее реализовать
• Проще обновить REST API

Аргументы за № 2:

• Что делать, если REST API должен быть версии отдельно от Java API? (Это несколько вероятно.)
• Что, если в классы данных Java будут внесены значительные изменения, такие как удаление свойств, добавление поведения или изменения в иерархию классов? (Это также несколько вероятно.)

Суть в том, что это похоже на компромисс между СУХОЙ (# 1) и развязкой (# 2).

Я склоняюсь к тому, чтобы начать с № 1, а затем, если возникнут проблемы, переместиться на № 2 позже, следуя гибкому руководству: не строить то, что вы не можете доказать, что вам нужно. Это плохая идея; Должен ли я начать с № 2, если я думаю, что я могу оказаться там в любом случае?

В моих списках отсутствуют основные аргументы / последствия?

Хороший вопрос, проще говоря, отделить. Это путь сюда, вы не хотите быть привязанным к версии Java.

Есть один сценарий, который вы не отделяете: если ваша технология позволит отправлять объекты по типу не по типу, то есть, если вы можете использовать текущие объекты Java сейчас как YAGNI, и замену другим настраиваемый вами тип будет простым раскрытием, которое ничего не сломает из-за информации о типе, передаваемой по проводам. Таким образом, в основном, если информация о типе не пересекает провод, вы можете использовать YAGNI.

Просто будьте очень осторожны и следите за тем, чтобы любые обновления вашей версии Java не изменяли ни один из этих объектов. В противном случае просто отделите сейчас и не беспокойтесь об этом, я думаю, это зависит от того, сколько у вас есть времени, если у вас есть выбор.

Тем не менее, если информация о типах передается по протоколу в протоколе, то плоское добавление новых типов при изменении базовых типов Java может оказаться невозможным и может потребовать больших усилий. В таком случае переход на YAGNI означает накопление технического долга и рисков, связанных с вашей базовой технологией.

Лично я бы сейчас отделился.

Кроме того, DRY не играет в это, потому что вы не написали основные части, поэтому вы не дублируете код и, следовательно, не будете повторять ошибки, повторяющиеся повсюду, что является главной проблемой DRY (и общей ремонтопригодности). проблемы, которые у вас снова не возникнут, потому что у вас нет дубликатов для обслуживания)

Основными аргументами для №1 являются простота внедрения и обновления, но отвечает ли она вашим требованиям?

В своих аргументах для # 2 вы указываете, что API Java и REST API могут изменяться независимо друг от друга. Это означает, что они являются отдельными проблемами, и вы не повторяете себя, используя отдельные классы. Просто потому , что две вещи , которые выглядят так же, не означает , что они являются одинаковыми.

Ваш REST API не должен следовать той же структуре, что и ваша модель данных

При реализации REST убедитесь, что вы создаете интуитивно понятный внешний API, а затем сопоставьте его с вашими внутренними классами модели данных. Это позволяет вам изменять каждый независимо от другого, приводя к API, которые могут длиться десятилетия .

Поэтому развязка - это путь сюда.