Маленькая выборка помноженная на когнитивные искажения, которые идут в дефолтной прошивке гомо сапиенса приводит к тому, что ценности от этих сообщений не сильно больше, чем от смс-гороскопов. Тельцам сегодня лучше держаться подальше от деревьев!
У Талеба классно расписано на примере 11 сентября. Предположим вы знаете, что такое может произойти и решили поработать с рисками. Вы вводите кучу запретов, дополнительных проверок, тратите на это уймы денег, народ верещит, вы красавчик, 11 сентября не случилось.
Но как это выглядит со стороны? Появилось куча сложностей, а "выгоды" как бы и нет. Ведь "11 сентября" и раньше не случалось безо всякой этой дополнительной возни и сумасшедших трат. И вот люди пишут про вас разгромные статьи, называя вас всякими словами, намекая на коррупцию и прочее.
Просто оно выдавало так много сообщений об усталости
Так МЧС себя иной раз ведет. Шлет кучу штормовых смс: если что произойдет – а мы же вас предупреждали, а нет – ну и ладно. Очевидно, что все начинают игнорировать такие "предупреждения".
Смотря какую задачу решать) Кто-то строит заборы на пути регистрации двойным указанием адреса, запретом копировать, подтверждением и т.п.
Меня как пользователя такое бесит, я готов взять риски неправильного указания почты на себя. Как и с физическим адресом. Я указываю куда прислать пиццу и чек/бумажку с моими персданными. И очевидно неправильно сперва меня просить подтвердить этот физический адрес.
Как я понимаю, у банка могут быть убыточные возвраты кэшбека. Такое компенсируется за счет чего-то другого или по определенной категории отменяют кэшбек вовсе (в России жкх и сотовая связь, например).
чем быстрее она окажется в проде, тем выше эффективность команды.
Это не так, если брать определение эффективности из статьи. То есть подход one-piece-flow дает оптимизацию времени, но при этом не обеспечивает оптимизацию пропускной способности.
Любая раскрытая информация вредит инкапсуляции, потому что рано или поздно люди начнут обращаться к внутрянке мойЗаказ.элементы[0]…
И приватные поля - отличный способ запретить такое использование. Можно, конечно, придумать конвенции и всем рассказать что можно а что нет, но рано или поздно начнет протекать.
Круто что вы строите агрегат со столь жесткими границами. В таком случае особых проблем не вижу, но и преимуществ такой организации кода тоже не нахожу)
Можно фрагментирован бизнес-логику как угодно. Но зачем? Тестабилити снижается, maintainability снижается, cohesion снижается. Одно дело когда из-за компромисса мы это делаем, но не понимаю зачем это делать нормой.
Скорее всего да, но к сожалению, не любой инвариант можно запихать в доменную модель.
Классический пример - требование уникальности никнейма (если это не локальные шашки на смартфоне). В таком случае вы делаете выбор между производительностью, полнотой модели и работой внутри одного процесса приложения (то что назвали purity).
Надо проверку инвариантов повторять в каждой функции, как я понял. Хотя если это просто вынос метода в отдельный класс, то немногое в этом отношении меняется, но тогда я не понимаю профита от такого выноса.
ООП предложило совместить данные и поведение. Одним из посылов было соблюдение инвариантов класса. В вашем случае знание инвариантов надо размазывать по всем функциям и не забыть поменять когда бизнес меняется. Но это нарушает принцип DRY и cohesion выходит не очень сильной.
Размещать инварианты чуть ли не в персистанс слое (как предлагалось здесь в комментах)? Ну это на любителя , примерно как строить систему на триггерах и хранимках - можно забыть о тестабилити
Маленькая выборка помноженная на когнитивные искажения, которые идут в дефолтной прошивке гомо сапиенса приводит к тому, что ценности от этих сообщений не сильно больше, чем от смс-гороскопов. Тельцам сегодня лучше держаться подальше от деревьев!
Задним числом можно легко и красиво рассуждать.
У Талеба классно расписано на примере 11 сентября. Предположим вы знаете, что такое может произойти и решили поработать с рисками. Вы вводите кучу запретов, дополнительных проверок, тратите на это уймы денег, народ верещит, вы красавчик, 11 сентября не случилось.
Но как это выглядит со стороны? Появилось куча сложностей, а "выгоды" как бы и нет. Ведь "11 сентября" и раньше не случалось безо всякой этой дополнительной возни и сумасшедших трат. И вот люди пишут про вас разгромные статьи, называя вас всякими словами, намекая на коррупцию и прочее.
Так МЧС себя иной раз ведет. Шлет кучу штормовых смс: если что произойдет – а мы же вас предупреждали, а нет – ну и ладно. Очевидно, что все начинают игнорировать такие "предупреждения".
Смотря какую задачу решать) Кто-то строит заборы на пути регистрации двойным указанием адреса, запретом копировать, подтверждением и т.п.
Меня как пользователя такое бесит, я готов взять риски неправильного указания почты на себя. Как и с физическим адресом. Я указываю куда прислать пиццу и чек/бумажку с моими персданными. И очевидно неправильно сперва меня просить подтвердить этот физический адрес.
Еще в офисе можно что-то продать, рекламу открутить или как-то иначе монетизировать приход живого человека.
Давно уже только так и скачивал. Еще бы магнет-ссылку бы они туда вывели вместо торрент-файла)
Как я понимаю, у банка могут быть убыточные возвраты кэшбека. Такое компенсируется за счет чего-то другого или по определенной категории отменяют кэшбек вовсе (в России жкх и сотовая связь, например).
Это не так, если брать определение эффективности из статьи. То есть подход one-piece-flow дает оптимизацию времени, но при этом не обеспечивает оптимизацию пропускной способности.
Для персистанс-слоя можно использовать дто.
Любая раскрытая информация вредит инкапсуляции, потому что рано или поздно люди начнут обращаться к внутрянке мойЗаказ.элементы[0]…
И приватные поля - отличный способ запретить такое использование. Можно, конечно, придумать конвенции и всем рассказать что можно а что нет, но рано или поздно начнет протекать.
Если общедоступного интерфейса недостаточно для проверки и для действия?
А объект.Действие() где? В сервисах?
Имеет ли валидатор и сервисы доступ к внутреннему устройству объекта? Правильно ли я понимаю, что вы топите за анемичную модель?
Круто что вы строите агрегат со столь жесткими границами. В таком случае особых проблем не вижу, но и преимуществ такой организации кода тоже не нахожу)
Можно фрагментирован бизнес-логику как угодно. Но зачем? Тестабилити снижается, maintainability снижается, cohesion снижается. Одно дело когда из-за компромисса мы это делаем, но не понимаю зачем это делать нормой.
Скорее всего да, но к сожалению, не любой инвариант можно запихать в доменную модель.
Классический пример - требование уникальности никнейма (если это не локальные шашки на смартфоне). В таком случае вы делаете выбор между производительностью, полнотой модели и работой внутри одного процесса приложения (то что назвали purity).
По-хорошему, его там не должно быть сохранено. Если логика поменялась в процессе, то надо предусмотреть что делать с легаси-заказами.
Можно запретить часть методов, то есть поднимать можно, а процессить нельзя.
Вы как-то проверяете, что модель изменяется только классами из этой же папочки?
Это инвариант для агрегата заказ, если нет особо других вводных.
Если не брать полуэкспериментальное проектирование по контракту, то также в коде и тестами.
Надо проверку инвариантов повторять в каждой функции, как я понял. Хотя если это просто вынос метода в отдельный класс, то немногое в этом отношении меняется, но тогда я не понимаю профита от такого выноса.
ООП предложило совместить данные и поведение. Одним из посылов было соблюдение инвариантов класса. В вашем случае знание инвариантов надо размазывать по всем функциям и не забыть поменять когда бизнес меняется. Но это нарушает принцип DRY и cohesion выходит не очень сильной.
Размещать инварианты чуть ли не в персистанс слое (как предлагалось здесь в комментах)? Ну это на любителя , примерно как строить систему на триггерах и хранимках - можно забыть о тестабилити