Как я понимаю, у банка могут быть убыточные возвраты кэшбека. Такое компенсируется за счет чего-то другого или по определенной категории отменяют кэшбек вовсе (в России жкх и сотовая связь, например).
чем быстрее она окажется в проде, тем выше эффективность команды.
Это не так, если брать определение эффективности из статьи. То есть подход one-piece-flow дает оптимизацию времени, но при этом не обеспечивает оптимизацию пропускной способности.
Любая раскрытая информация вредит инкапсуляции, потому что рано или поздно люди начнут обращаться к внутрянке мойЗаказ.элементы[0]…
И приватные поля - отличный способ запретить такое использование. Можно, конечно, придумать конвенции и всем рассказать что можно а что нет, но рано или поздно начнет протекать.
Круто что вы строите агрегат со столь жесткими границами. В таком случае особых проблем не вижу, но и преимуществ такой организации кода тоже не нахожу)
Можно фрагментирован бизнес-логику как угодно. Но зачем? Тестабилити снижается, maintainability снижается, cohesion снижается. Одно дело когда из-за компромисса мы это делаем, но не понимаю зачем это делать нормой.
Скорее всего да, но к сожалению, не любой инвариант можно запихать в доменную модель.
Классический пример - требование уникальности никнейма (если это не локальные шашки на смартфоне). В таком случае вы делаете выбор между производительностью, полнотой модели и работой внутри одного процесса приложения (то что назвали purity).
Надо проверку инвариантов повторять в каждой функции, как я понял. Хотя если это просто вынос метода в отдельный класс, то немногое в этом отношении меняется, но тогда я не понимаю профита от такого выноса.
ООП предложило совместить данные и поведение. Одним из посылов было соблюдение инвариантов класса. В вашем случае знание инвариантов надо размазывать по всем функциям и не забыть поменять когда бизнес меняется. Но это нарушает принцип DRY и cohesion выходит не очень сильной.
Размещать инварианты чуть ли не в персистанс слое (как предлагалось здесь в комментах)? Ну это на любителя , примерно как строить систему на триггерах и хранимках - можно забыть о тестабилити
Доменная модель не знает как она будет храниться. Некоторые авторы называют идеальным хранилищем документоориентированные бд. Так что абзац про орм немного не про то что написано.
В таком случае orderAggregate становится тем самым сервисом от которого я призываю отказаться. Ну и кучу зависимостей в метод Calculate при правильной нарезке обычно не придется передавать.
мы не можем диктовать эксперту со склада, как он должен называть свои сущности. Мы должны код подстроить под доменные знания. И чтобы путаницы не было - делим на контексты, каждый термин внутри контекста однозначно понятен и для доменных экспертов, и для разработчиков.
Макс, мне кажется, что такое описание ubiquitous language может сбить с толку.
Единый язык создается не для проекта, а для контекста. И в каждом контексте слово «заказ» будет обозначать что-то свое.
Если брать пример из активити диаграммы, там может быть пяток контекстов (магазин, разные менеджеры). При этом везде будет заказ, но со своими атрибутами, со своим бизнес-процессом. И уход от единой универсальной модели Заказа и есть избежание антипаттерна GodObject.
У нас на географии не рассказывали про особенности мусульманских календарей. Да и переход на зимнее/летнее время казался таким же неизбежным как и Новый год)
Как я понимаю, у банка могут быть убыточные возвраты кэшбека. Такое компенсируется за счет чего-то другого или по определенной категории отменяют кэшбек вовсе (в России жкх и сотовая связь, например).
Это не так, если брать определение эффективности из статьи. То есть подход one-piece-flow дает оптимизацию времени, но при этом не обеспечивает оптимизацию пропускной способности.
Для персистанс-слоя можно использовать дто.
Любая раскрытая информация вредит инкапсуляции, потому что рано или поздно люди начнут обращаться к внутрянке мойЗаказ.элементы[0]…
И приватные поля - отличный способ запретить такое использование. Можно, конечно, придумать конвенции и всем рассказать что можно а что нет, но рано или поздно начнет протекать.
Если общедоступного интерфейса недостаточно для проверки и для действия?
А объект.Действие() где? В сервисах?
Имеет ли валидатор и сервисы доступ к внутреннему устройству объекта? Правильно ли я понимаю, что вы топите за анемичную модель?
Круто что вы строите агрегат со столь жесткими границами. В таком случае особых проблем не вижу, но и преимуществ такой организации кода тоже не нахожу)
Можно фрагментирован бизнес-логику как угодно. Но зачем? Тестабилити снижается, maintainability снижается, cohesion снижается. Одно дело когда из-за компромисса мы это делаем, но не понимаю зачем это делать нормой.
Скорее всего да, но к сожалению, не любой инвариант можно запихать в доменную модель.
Классический пример - требование уникальности никнейма (если это не локальные шашки на смартфоне). В таком случае вы делаете выбор между производительностью, полнотой модели и работой внутри одного процесса приложения (то что назвали purity).
По-хорошему, его там не должно быть сохранено. Если логика поменялась в процессе, то надо предусмотреть что делать с легаси-заказами.
Можно запретить часть методов, то есть поднимать можно, а процессить нельзя.
Вы как-то проверяете, что модель изменяется только классами из этой же папочки?
Это инвариант для агрегата заказ, если нет особо других вводных.
Если не брать полуэкспериментальное проектирование по контракту, то также в коде и тестами.
Надо проверку инвариантов повторять в каждой функции, как я понял. Хотя если это просто вынос метода в отдельный класс, то немногое в этом отношении меняется, но тогда я не понимаю профита от такого выноса.
ООП предложило совместить данные и поведение. Одним из посылов было соблюдение инвариантов класса. В вашем случае знание инвариантов надо размазывать по всем функциям и не забыть поменять когда бизнес меняется. Но это нарушает принцип DRY и cohesion выходит не очень сильной.
Размещать инварианты чуть ли не в персистанс слое (как предлагалось здесь в комментах)? Ну это на любителя , примерно как строить систему на триггерах и хранимках - можно забыть о тестабилити
В свое время очень зашла книга Рефакторинг SQL приложений Фаро. Скорее всего она и сейчас остается актуальной, несмотря на возраст.
Доменная модель не знает как она будет храниться. Некоторые авторы называют идеальным хранилищем документоориентированные бд. Так что абзац про орм немного не про то что написано.
В таком случае orderAggregate становится тем самым сервисом от которого я призываю отказаться. Ну и кучу зависимостей в метод Calculate при правильной нарезке обычно не придется передавать.
Сорри, за -1, мисклик(
мы не можем диктовать эксперту со склада, как он должен называть свои сущности. Мы должны код подстроить под доменные знания. И чтобы путаницы не было - делим на контексты, каждый термин внутри контекста однозначно понятен и для доменных экспертов, и для разработчиков.
Макс, мне кажется, что такое описание ubiquitous language может сбить с толку.
Единый язык создается не для проекта, а для контекста. И в каждом контексте слово «заказ» будет обозначать что-то свое.
Если брать пример из активити диаграммы, там может быть пяток контекстов (магазин, разные менеджеры). При этом везде будет заказ, но со своими атрибутами, со своим бизнес-процессом. И уход от единой универсальной модели Заказа и есть избежание антипаттерна GodObject.
Не так давно проверял - был «трояном». Рад что они отказались от этой мерзкой практики обеспечения «безопасности».
У нас на географии не рассказывали про особенности мусульманских календарей. Да и переход на зимнее/летнее время казался таким же неизбежным как и Новый год)