Вероятнее всего я просто не правильно выставил уровень сложности статьи. Ожидается, что читатель уже обладает знаниями о том, что такое зависимости, дерево зависимостей и тд.
Не очень понятно что вы имеете ввиду под подсказкой. В статье упомянуто:
Удобнее всего выносить версии библиотек в переменные. Это поможет проще переопределять версию зависимости в конкретном микросервисе в случае крайней необходимости.
Вы описали пример того, как это сделать или у вас вопрос по тому, что в наследнике можно переопределять версии парента?
Для чего нужна схема? Я развернуто ответил на этот вопрос в предыдущем комментарии.
Зачем генерировать каждый раз при сборке проекта? Для того, чтобы при изменении схемы генерировались обновленные классы. При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме, нежели в большом количестве классов. Генерация занимает всего доли секунды и практически не влияет на общее время сборки проекта.
По поводу бизнес логики в dto и прочее: что такое dto? Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices. Dto должны быть простыми и содержать только данные, не содержать бизнес логики, данные должны валидироваться ДО создания dto и т.д.
В случае с большим классом необходимо потратить достаточно много времени на его описание в соответствии с примером json ответа сервера. Если ли же будет несколько эндпоинтов, то на каждый из них нужно писать свой большой класс, что увеличивает количество этих классов. А что если нужно написать интеграцию с несколькими серверами? Помимо описания ответа сервера могут быть еще и сложные dto для запросов. Это также дополнительные классы.
В случае генерации, для начала, можно воспользоваться онлайн генератором схемы из примера json ответа сервера. Дальше уже можно использовать эту схему как угодно:
Скорректировать ее по вашему усмотрению (переименовать классы, вынести все в defenitions и тд)
Можно наследоваться от генерируемых файлов, переопределяя свойства, которые необходимы или подкладывать свои реализации. В этом случае нужно в defenitions добавить что-то вроде:
Либо же можно просто скопировать сгенерированные файлы в привычное место и просто использовать их как обычные java классы. Тут уже решать вам.
Выигрыш от генерации файлов я вижу следующий:
Генерация классов по готовому json ответу занимает меньше времени, чем описание их вручную (конечно, можно воспользоваться онлайн генераторами классов из json ответа сервера)
Описание всего ответа сразу перед глазами в удобном формате
Гибкая настройка генерации (можно добавить генерацию билдеров одной настройкой плагина)
Можно спрятать большое количество dto файлов, чтобы они не мешали чтению проекта
Возможность подменять внутренние классы своими реализациями
Конечно приходилось. Поэтому автор указал тэги java и maven. Естественно, если в системе микросервисы на JavaScript, PHP и тд, то какой тут maven?
Вероятнее всего я просто не правильно выставил уровень сложности статьи. Ожидается, что читатель уже обладает знаниями о том, что такое зависимости, дерево зависимостей и тд.
Не очень понятно что вы имеете ввиду под подсказкой. В статье упомянуто:
Вы описали пример того, как это сделать или у вас вопрос по тому, что в наследнике можно переопределять версии парента?
Давайте еще раз по порядку.
Для чего нужна схема? Я развернуто ответил на этот вопрос в предыдущем комментарии.
Зачем генерировать каждый раз при сборке проекта? Для того, чтобы при изменении схемы генерировались обновленные классы. При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме, нежели в большом количестве классов. Генерация занимает всего доли секунды и практически не влияет на общее время сборки проекта.
По поводу бизнес логики в dto и прочее: что такое dto? Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices. Dto должны быть простыми и содержать только данные, не содержать бизнес логики, данные должны валидироваться ДО создания dto и т.д.
В случае с большим классом необходимо потратить достаточно много времени на его описание в соответствии с примером json ответа сервера. Если ли же будет несколько эндпоинтов, то на каждый из них нужно писать свой большой класс, что увеличивает количество этих классов. А что если нужно написать интеграцию с несколькими серверами? Помимо описания ответа сервера могут быть еще и сложные dto для запросов. Это также дополнительные классы.
В случае генерации, для начала, можно воспользоваться онлайн генератором схемы из примера json ответа сервера. Дальше уже можно использовать эту схему как угодно:
Скорректировать ее по вашему усмотрению (переименовать классы, вынести все в defenitions и тд)
Можно наследоваться от генерируемых файлов, переопределяя свойства, которые необходимы или подкладывать свои реализации. В этом случае нужно в defenitions добавить что-то вроде:
И его уже использовать как $ref
Либо же можно просто скопировать сгенерированные файлы в привычное место и просто использовать их как обычные java классы. Тут уже решать вам.
Выигрыш от генерации файлов я вижу следующий:
Генерация классов по готовому json ответу занимает меньше времени, чем описание их вручную (конечно, можно воспользоваться онлайн генераторами классов из json ответа сервера)
Описание всего ответа сразу перед глазами в удобном формате
Гибкая настройка генерации (можно добавить генерацию билдеров одной настройкой плагина)
Можно спрятать большое количество dto файлов, чтобы они не мешали чтению проекта
Возможность подменять внутренние классы своими реализациями