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

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

PJ>Квазистатическое окружение тут не причем. У вас неправильно потому, что проблемы там, где их быть не должно.


PJ>Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?
Ясно. Вижу, что рефакторинг вы видели только по телевизору. Ознакомьтесь, с тем, как работают реальные, а не воображаемые инструменты: https://www.jetbrains.com/help/resharper/Refactorings__Introduce_Parameter.html
Добавление параметра поправит все call sites, включая, естественно, тесты. А иначе нахрена такой рефакторинг нужен?

PJ>Это уже отдельная фича, про нее речи не было, просто как дополнительный пример привел.


S>>Ну, и непонятно, что значит "нельзя выставлять наружу". Я себе не представляю такую систему. Что у вас, каждая-прекаждая ссылка — nullable? В жизни не поверю.
PJ>Ну что ты, у меня вообще nullable нет. F# Нельзя выставлять наружу означает, что нельзя выставлять наружу. Наружу выставляется производная от модели — dto объект. Все в книжках есть, кстати.
(facepalm). Ну ок, пусть будет DTO объект. У нас, к примеру, всё выставлено наружу как JSON. И у этого JSON есть модель — schema. Она, естественно, соответствует той модели, которая внутри. И в этой схеме сказано, что подписка — обязательный атрибут.

PJ>Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.
Да при чём тут grpc? Вы говорите про самый низкий уровень, неинтересные детали. Речь о том, что от изобретения нового контракта никакая магия не сделает всех клиентов старого контракта совместимыми с новым.
И вы никаким образом не сохраните инварианты старого контракта — банальный GetBalance, который вроде бы не изменился по сигнатуре, теперь не может возвращать сумму, которая совпадает с суммой всех ордеров.

PJ>Подписка или покупка это оплата, разве нет? Я только гадать могу о твоей задаче, ты ее не расписал.
Оплата — это передача денег. Ордер — это заказ. Если, допустим, пользователь Poopy Joe что-то заказал на 100 долларов, то его баланс уменьшился на 100 долларов.
Если пользователь заплатил 200 долларов, то его баланс увеличился на 200 долларов. Это вещи, мало связанные между собой.
Есть понятные любому менеджеру инварианты: баланс Джо равен сумме всех его платежей минус сумма всех заказов (пренебрегаем коррекциями).
Введение нового типа заказа означает, что либо мы ломаем сигнатуру методов по получению заказов, либо у нас ломается инвариант баланса.
Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.

PJ>Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию.
Да, именно об этом и речь — надо переписывать.

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

PJ>То, что они ничего друг про друга не знают, не означает, что система не зависит от их согласованности. Есть допустим 4 камеры, которые формируют картинку. Камеры независимы. Т.е. если одну убрать, то картинка будет из трех, это не проблема. Проблема в том, что баланс белого должен быть у всех одинаковый. Если инженер провел рекалибровку и один из файлов сдох, то откатывать надо все, иначе изображение будет некорректным. Пока версионности не было, не было и такой проблемы, было одно состояния в одной версии файла у каждого устройства.
Ну, не было так не было. Хотя как я понял, версионность как раз была решением, а не проблемой. Впрочем, я уже понял, что мы с вами не договоримся — вы называете багфикс фичей, дополнение рефакторингом, а решение — проблемой. Ну, ваше право, чо. Не удивляйтесь только, что все остальные вас не понимают