Преза 2014-го года. Надеюсь, Luxoft не будет иметь претензий. Преза с некоммерческого семинара и на тот момент у автора не было юридических отношений с компанией. Многие концепты до сих пор актуальным.

Тогда ещё было не понятно, кто "победит", Swagger или RAML

Для трушного Contract-First, то есть для генерации кода из дефинишена пришлось немного допилить кодогенератор. Сейчас с этим нет проблем.

Я так понимаю это ваша настольная книга?
https://i.imgur.com/7IQbWD9.png

сейчас с OpenAPI 3.0 генератором тоже приходиться потанцевать перед тем как использовать его.

Сам не смотрел. Значит я оказался излишне оптимистичен)

Мне не нравятся кодогенераторы в том, что они генерят то, что нужно потом дописывать. А не экстендить. Таким образом нет нормального процесса апдейта спеки (сгенерил новый код -> проект не собрался/тесты не прошли -> дописал/исправил). Получается, что если в сгенеренном коде есть изменения, то при новой генерации они стираются. А если бы изменений не было, то код генерированный можно было бы даже не хранить в гите

Я сейчас скажу, возможно, очень страшную вещь, но архитектура конкретного сервиса она не в бумагах и не в карточках сервисов.

Между прочим её даже в коде нету. Если уже на то пошло.

Она где-то рядом с разрухой по Преображенскому 😬

- кодогенератор можно дописать под нужную структуру, что мы и делали
- можно "защититься" интерфейсами, причём так, что относительно безболезно возможна будет кодогенерация (перегерация)

С WSDL было то же самое, в итоге получалось перегерировать без больших потерь

Примерно так) Я к тому, что есть процедура определения соответствия кода общему дизайну.
Если у вас её нету - мои соболезнования.

В то, что генерируется по WSDL я один раз в жизни залез

Ну да. Но чтобы определить, нужно сначала "увидеть", а чтобы увидеть нужно иметь задокументированный дизайн

Именно.

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

Но такой подход сложный, для его реализации нужны соотв навыки и воля.

Поэтому чаще всего дефинишен генерируется из кода. Но опять же, на основе стабов сначала. Чтобы побыстрее "допилить" API и зашерить его дефинишен

Если у нас есть некий дизайн, которому что-то должно соответствовать, то почему оно не часть ТЗ?

А если оно не часть ТЗ, то почему оно должно ему соответствовать?

А давайте ТЗ и дизайн не путать

Есть. Все кодогенераторы ужасны (

Если мы говорим про результат, то да, не надо путать. А если мы говорим про то, что реализация должна соответствовать каким-то правилам, то эти правила есть часть ТЗ.

Нет. Вы путаете задачи проектирования и производства.