Здравствуйте, _ABC_, Вы писали:

_AB>Интересно, когда до тебя дойдет, что всегда софт разрабатывается на основе предположений той или иной степени детализированности и подтвержденности...
Интересно до тебя дойдет, что таким тоном ты будешь общаться сам с собой, в основном? Можешь просто не тратить усилий на набивание текста.

_AB>Вот, например, клиент заказал разработку системы, которая должна перевернуть его индустрию. Клиент очень много усилий и денег посвятил разработке модели, дизайна, общался со своими клиентами, опираясь на свой огромный опыт в индустрии писал ТЗ. Делал презентации, собирал фидбек. Собирал группы клиентов и проводил практические сессии. Он потратил несколько месяцев на это. Мы сделали всё, как просили. Оказалось, что предположения, которые делали и клиент и клиенты клиентов по поводу того, как им хотелось бы работать с системой, оказались несколько неверными. Причем в некоторых вещах кардинально неверными. К счастью, т.к. и наш клиент и мы сами имеем опыт работы, мы с самого начала ориентировались на выпуск MVP с последующей переоценкой, поэтому "много денег и усилий" не оказалось "чрезмерно много денег и усилий" и большую часть разработанного можно использовать или переделать с минимальными потерями.

Спасибо кэп, кто бы мог подумать, что требования могут меняться?!
Модель может строится на предположениях, API должно строится на сценариях использования.
Сценарий ты можешь предполагать, и предположение может отказаться неверным, но внутри него никаких предположений нет. Если там есть subscription-id, то есть и ответ зачем, иначе это не сценарий.

PJ>>Есть множество практик как подобного избегать, то же DDD например.
_AB>Ну и как эта практика помогает полностью избежать неопределенности, сложности и изменчивости окружающего мира?
Четко разделяя приложение на ограниченные контексты, изолируя модель от внешнего мира, разделяя логику и окружение внешнего мира и там еще много чего есть.