Здравствуйте, Poopy Joe, Вы писали:
PJ>От product onwer, разумеется.
Кто такой product owner? Ну, вот на понятном всем примере — кто такой product owner у visual studio?
PJ>Что значит порядок выдачи? Ты назвал одну задачу "отчет в pdf" как ее можно выдать, если половина не сделана?
Почему не сделана? Сделана. И вторая половина сделана. А вот что важнее — отчёт в PDF или интеграция с SAP R3 — решает не программист.

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

PJ>А кто говорил про ГОДЫ вперед? Достаточно и года.
Слишком много. Вот сейчас мы знаем, что в феврале 2021 у Microsoft выйдет New commerce platform. Точнее, на неё переведут license-based services.
Казалось бы — три квартала всего осталось, надо бечь детально планировать.
По факту: в чём именно состоит этот перевод — никто пока не знает. В том числе и в Microsoft. Они пока обдумывают идеи того, как это будет выражено в API.
Ну, и какая там будет модель по ту сторону API, тоже пока никто не знает.
А значит и смысла ничего планировать нет. Может оказаться, что мы это поддержим за 4 часа работы разработчика, 30 часов регрессии, и 80 часов работы продакт менеджера — по написанию презентаций про то, как мы круто всё поддерживаем.
А может, окажется что они в очередной раз перепилили всё поперёк прежнего, и наше отражение их модели придётся переделывать на 70%.
А может, они перенесут сроки ещё на год — первоначально они собирались всё это в продакшн в феврале 2020.

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

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

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

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

Даже если и так, то это ничему не поможет. Ну, напишем мы в документации на API, что атрибут "подписка" является необязательным.
Люди-то интегрируются не с документацией, а с живой системой. Если они видят, что по факту subscription всегда есть, то они пишут код, который на это рассчитывает.
Сделав атрибут необязательным, мы обманем сами себя. Нам будет казаться, что можно его не задавать, а по факту — такой релиз вызовет массовые отказы кода у клиентов.

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

PJ>Это я сильно сомневаюсь. Ну может там бизнес часть чего и не знала, я сомневаюсь на счет всего остального.

PJ>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
Не, это реальность.

PJ>Так весь смысл DDD заключается именно в этом. Как иметь модель предметной области, менять ее и при этом не страдать.


PJ>А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?
Для начала надо попытаться разобраться, зачем откатывать все — ведь они же друг про друга ничего не знают, значит понятие "несогласованность" возникнуть никак не может.
Если получается так, что они себя ведут некорректно, если у одного конфигурация версии 1, а у другого — 2, то значит нет никакой независимости, и вы со своей DDD себя обманываете, вводя иллюзию изоляции.
Дальше, когда мы поняли, что модули на самом деле взаимосвязаны, можно делать рефакторинг — например, дублирующийся код по чтению и записи файлов конфигурации выносим в общий для всех модуль. Если он, по непонятной причине, таки оказался размазан. Рефакторинг хорош тем, что мы гарантированно ничего не делаем хуже: это цепочка инвариантных преобразований кода.

Если нет — то даже рефакторить не нужно: меняем только ту часть, которая работает непосредственно с файлами. Вставляем один дополнительный уровень каталога между нынешним местом хранения и именем файла.
В начале операции "сохранить конфигурацию" каталог получает временное имя; если всё кончилось успешно — переименовываем его в номер версии. Если нет — фиг с ним, останется недописанный каталог с кривым именем.
На старте, при чтении конфигурации, мы выбираем каталог с максимальным номером — в нём живёт гарантированно консистентная конфигурация. Всё.
Всей работы, не считая рефакторинга — на пару часов вместе с написанием тестов и перерывом на кофе.
Наверняка всё гораздо сложнее, потому чт оесть особенности, которые вы опустили. Но со стороны чужие проблемы выглядят именно так.