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

S>Кто такой product owner? Ну, вот на понятном всем примере — кто такой product owner у visual studio?
https://www.scrum.org/resources/what-is-a-product-owner

PJ>>Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?
S>Почему не сделана? Сделана. И вторая половина сделана. А вот что важнее — отчёт в PDF или интеграция с SAP R3 — решает не программист.
Что такое вторая половина? Есть задача, есть AC. Какие такие половины, оно либо сделано либо нет.

PJ>>Решает ага. Я только не понял в каком месте я с этим спорил?
S>Да всю ветку.
Ты что-то не так понял или не слушал.

PJ>>А кто говорил про ГОДЫ вперед? Достаточно и года.
S>Слишком много. Вот сейчас мы знаем, что в феврале 2021 у Microsoft выйдет New commerce platform. Точнее, на неё переведут license-based services.
Для вас может много, для нас нормально.

PJ>>Может не стоит натягивать свою сову на общий глобус?
S>Того же и вам желаю. Делать выводы о том, что у кого-то что-то неправильно потому, что вы имеете роскошь жить в квазистатическом окружении — смело.
Квазистатическое окружение тут не причем. У вас неправильно потому, что проблемы там, где их быть не должно.

PJ>>Ну как же не найду-то? Добавить параметр в метод есть уже примерно везде. А это уже влияет на тесты и меняет поведение.
S>Это у вас какой-то негодный инструмент. В моём инструменте добавление параметра в метод добавит его не только в метод (это я и сам могу без инструмента), а подобавляет его везде, в том числе и в тестах.
Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?

PJ>>Ну да, если к компу приставить упс, то раньше он выключался при пропадании питания, а теперь перестал — багфикс, че. И нет, это никто не продает как фичу, фичи могут быть и внутренними. Скажем в данном случае это позволяет имея историю изменений калибровки, отслеживать деградацию лампы. Что тоже нафиг не надо клиентам, но полезно нашим инженерам.
S>Это совершенно нормально — пользователями системы являются вовсе не только клиенты. Но мы опять приходим к тому, что вы ведёте про вполне себе наблюдаемое изменение вашими инженерами изменение внешнего поведения. А стало быть это — обычное, нормальное изменение.
Это уже отдельная фича, про нее речи не было, просто как дополнительный пример привел.

S>Да, вы даже наверное могли пилить сам код по версионному сохранению вообще в отрыве от остального приложения; а рефакторингом, нужным для интеграции, заняться в конце.
Я равно это и написал. Вот только эта версионность без рефакторинга смысла не имеет. Я не могу их разделить, если уж каких-то совсем странных вещей не делать, религиозной чистоты ради.

PJ>>Потому что неявно подразумевается ее неизменность, что очевидно не так. Не говоря уж о том, что просто нельзя выставлять наружу.
S>А где вы видели модели, в которых бы кардинальность связей подразумевалась изменяемой?
S>Ну, и непонятно, что значит "нельзя выставлять наружу". Я себе не представляю такую систему. Что у вас, каждая-прекаждая ссылка — nullable? В жизни не поверю.
Ну что ты, у меня вообще nullable нет. F# Нельзя выставлять наружу означает, что нельзя выставлять наружу. Наружу выставляется производная от модели — dto объект. Все в книжках есть, кстати.

S>Даже если и так, то это ничему не поможет. Ну, напишем мы в документации на API, что атрибут "подписка" является необязательным.
Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.

PJ>>И? Пусть они на нем и живут. Появиться второй контракт для отдельной покупки. Он даже придет в тот же порт, но уже в другое место, к другому обработчику, который знает что с этим делать. Полагаю, следующий рояль в кустах это странно использование этой подписки всеми, вместо дериватива операции оплаты.
S>При чём тут оплата? Оплата связана с ордером. Второй контракт — это отличная идея.
Подписка или покупка это оплата, разве нет? Я только гадать могу о твоей задаче, ты ее не расписал.

S>Вот, был, скажем, контракт "GetAllOrdersForTimePeriod()", который возвращал наши "старые" ордера. Его использовали клиенты для того, чтобы создавать дубликаты ордеров у себя в отчётных системах.
S>Все работает годами, а потом мы выпускаем новый параллельный контракт, GetAllModernOrdersForTimePeriod(). Типа новые-то ордера мы не можем отдавать через старый — они инварианту не удовлетворяют.
S>И чем это лучше? У клиента-то обороты стали расходиться — ну, или ему надо перепиливать ту часть своей интеграции, которая отвечает за копирование ордеров.
Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию. Если клиенту это несущественно, то клиенту надо было слать не ордера, а опять же их производные, где возможно и нет разницы между покупкой и подпиской.

PJ>>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
S>Не, это реальность.
В чем тут реальность? Как это сделать описано в DDD. Реальность в том, что ты не будешь их читать?

PJ>>А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?
S>Для начала надо попытаться разобраться, зачем откатывать все — ведь они же друг про друга ничего не знают, значит понятие "несогласованность" возникнуть никак не может.
То, что они ничего друг про друга не знают, не означает, что система не зависит от их согласованности. Есть допустим 4 камеры, которые формируют картинку. Камеры независимы. Т.е. если одну убрать, то картинка будет из трех, это не проблема. Проблема в том, что баланс белого должен быть у всех одинаковый. Если инженер провел рекалибровку и один из файлов сдох, то откатывать надо все, иначе изображение будет некорректным. Пока версионности не было, не было и такой проблемы, было одно состояния в одной версии файла у каждого устройства.