Можете хранить где-то список позиций для пользователя и каждый раз считать итоговую сумму
Вот меня и интересует, где хранить список позиций.
Да, «итого» может быть в read-модели. Но инкрементировать его нельзя, мы же не можем использовать данное значение, находясь в контексте write-модели.
Если у вас при изменение какой-то сущности важно знать состояние юзера, то поместите эту сущность в User агрегат.
В пределе тогда вся логика окажется в классе UserAR :)
Своим вопросом я пытаюсь понять, как предлагается реализовывать непосредственно правила бизнес-логики. Всегда будет необходимость во взаимодействии двух или более объектов. И они легко могут быть из разных агрегатов. Но подход с сокрытием состояния явно мешает подобному взаимодействию. Может просто исходная методология этого не подразумевает на самом деле?
У меня в голове всё же был более простой пример. Ну допустим, корзина в интернет-магазине. Она состоит из позиций (наименование товара, кол-во, сумма). Пользователю нужно показать «Итого». Или сгенерировать правильную сумму для оплаты через платёжную систему. Т.е. для всех добавленных в корзину товаров — получить стоимость каждого, с учётом желаемого количества. Глядя на исходники на github, не представляю как реализовать подобное поведение. Прямо вот напрашивается disclaimer к статье, гласящий о том, что данный подход актуален лишь для некоторого подмножества систем.
Почитал пример на github, сразу же возник вопрос (который собственно в статье и не освещён): у класса UserAR есть только методы по изменению его состояния. Что логично, исходя из всей идеи — объект же будет получать только команды по обновлению своего состояния, а отображаться пользователю данное состояние будет только из read-базы. Но что делать, когда в предметной области необходимо провернуть взаимодействие между двумя объектами? Очевидно, что при таком раскладе чьё-то состояние для начала придётся прочитать. Где его взять то?
Конкретно по 2й части статьи: мне одному кажется, что UserAR, UserState, UserИзReadБазы — это уже немножко много и очень похоже на разработку вокруг конкретной технологии, а никак не вокруг модели (DDD)?
Просто легонечко придерусь: статья называется "… методом ангелов", в тексте предлагается рассмотреть «метод ангелов». Но что же это такое — чёткого определения я не нашёл!
Я могу совершенно в таком же ключе придумать экстремальные случаи и про негативный эффект от рекламы. Но зачем? Сути это не меняет: реклама отнимает время на просмотр. Иногда человек готов его потратить, иногда — нет. Я, зачастую, нет.
Да всё же просто! Есть случаи, где ООП не хватает инструментов и выразительности для лёгкого решения задачи. Поэтому есть задокументированные костыли — паттерны. Чем больше костылей, значит тем больше дыр в изначальной парадигме, которые необходимо заткнуть. В ФП например «стратегия» не нужна, потому что подобный подход является частью самой парадигмы и является естественным для неё.
Окей, у нас есть DTO Person и мы переживаем, что пользователь о нём знает всё. Знает что там есть firstName, lastName и оперирует ими для своий целей. Что делать то тогда, чтобы избежать описанной вами проблемы?
Можно поподробнее про DTO, а точнее про логическую инкапсуляцию, нарушаемую для DTO. Вы имеете ввиду, что DTO — не объекты, поэтому для них не выполняются (не нужны) абстракции, полиморфизм, инкапсуляция и т.д. Если мы пример расширитель сознания и посмотрим на мир так, будто DTO стало объектом, то возможность получить доступ к его данным — нарушит инкапсуляцию, которой он на самом деле должен обладать, т.к. является объектом?
Мне кажется я реально стал понимать точку зрения вашего лагеря :)
На хабре недавно проскакивала статья про фабрики фабрик фабрик для производства молотков. Складывается ощущение, что та статья была не шуточной, а в какой-то степени действительно отражала правду.
По факту, смысл вашего комментария сводится к тому, что следуя ООП ребята впустую потратили 30 минут времени каждого (минимум, 1 человеко-час) и получили такой же выхлоп, как и мгновенное решение с использованием одного if. Здесь даже не поспоришь, это суровая действительность.
Однако, ребята сами виноваты :) Ещё Фаулер в PoEAA чёрным по белому писал: ребята, transaction script — это быстро, эффективно, но не приветствует изменений и не сильно способствует читаемости кода (в экстремальном случае). Domain model — это на старте ощутимо дольше и дороже. Профит в плане снижения сложности внесения изменений появляется только при достижении конкретного объема модели. До него — transaction script эффективней. По-моему, в книге даже был график. Ребята — сами виноваты. Ваше решение лучше по всем критериям! Только if — это не «совсем не ООПшный подход». ООП не запрещает в логике класса использовать условие. Оно просто говорит, что данный подход немного менее очевидный и понятие, лежащее в основе данного условия мы намеренно делаем менее явным и прячем от взора разработчика. Если окажется, что оно было важным — то epic fail. Если более 2х лет нам на него было начихать — okay.
Хочу ещё прокомментировать один момент. Вы чуточку не правы про усложнение или неусложнение системы. Наплодив больше классов, мы увеличиваем количественную сложность системы. Да, классов больше. Качественная сложность может даже наоборот снижаться. У нас же есть мощные инструменты — абстракция и инкапсуляция. Ну и что, что за реализацией данного интерфейса лежат ещё 2 класса и куча условной логики. Мне, как клиенту данного кода — жить прекрасно и шоколадно. А разработчику данного кода — что 1 класс, что 2, что 3 — по сути, равноценно. ООП позволило нам разбить программу на подобласти и под-подобласти, в каждой из которой мир просто, понятен и пушист. А то, что в сумме это на самом деле робот для убийства всех человеков — ну, okay :))
Не буду отрицать, что соблазн кинуться в моделирование очень велик и по факту затраты на подобное моделирование могут оказаться выше, нежели решить задачу «в лоб». Точно такая же проблема наблюдается с GoF (имхо) — велик соблазн абстрагировать в каком-нибудь паттерне каждый технический чих в программе. Но ведь всё это справедливо для неокрепших, начинающих умов! ООП даёт нам слишком много свободы и поэтому ею тяжелее распорядиться правильно. Поэтому нужно сильнее себя контролировать и чаще оглядываться назад, нежели смотреть в светлое будущее, когда наш калькулятор наверное будет забирать с биржи текущие котировки валют и уметь переводить из одной в другую. Нам в этом помогают всевозможные DDD (в книжке Эванса, по-моему, чуть ли не каждый спорный нюанс из комментариев к обеим статьям рассмотрен). Как награда за наши старания — в грамотно спроектированном ПО по ООП подходу действительно будет проще вносить изменения и действительно будет проще разобраться стороннему программисту.
У меня вот авто — Subaru. Считается, что она позволяет ездить быстрее 80% остальных авто. У меня нет к ней претензий, потому что хотя велик соблазн почудить, особенно зимой, я включаю мозг и так не делаю! Несколько раз (месяцев) потренировался на закрытой площадке и действительно, когда необходимо — я могу на ней ездить быстрее остальных.
Вот меня и интересует, где хранить список позиций.
Да, «итого» может быть в read-модели. Но инкрементировать его нельзя, мы же не можем использовать данное значение, находясь в контексте write-модели.
В пределе тогда вся логика окажется в классе UserAR :)
Своим вопросом я пытаюсь понять, как предлагается реализовывать непосредственно правила бизнес-логики. Всегда будет необходимость во взаимодействии двух или более объектов. И они легко могут быть из разных агрегатов. Но подход с сокрытием состояния явно мешает подобному взаимодействию. Может просто исходная методология этого не подразумевает на самом деле?
Конкретно по 2й части статьи: мне одному кажется, что UserAR, UserState, UserИзReadБазы — это уже немножко много и очень похоже на разработку вокруг конкретной технологии, а никак не вокруг модели (DDD)?
Я думаю, именно это вам пытаются сказать.
На хабре недавно проскакивала статья про фабрики фабрик фабрик для производства молотков. Складывается ощущение, что та статья была не шуточной, а в какой-то степени действительно отражала правду.
По факту, смысл вашего комментария сводится к тому, что следуя ООП ребята впустую потратили 30 минут времени каждого (минимум, 1 человеко-час) и получили такой же выхлоп, как и мгновенное решение с использованием одного if. Здесь даже не поспоришь, это суровая действительность.
Однако, ребята сами виноваты :) Ещё Фаулер в PoEAA чёрным по белому писал: ребята, transaction script — это быстро, эффективно, но не приветствует изменений и не сильно способствует читаемости кода (в экстремальном случае). Domain model — это на старте ощутимо дольше и дороже. Профит в плане снижения сложности внесения изменений появляется только при достижении конкретного объема модели. До него — transaction script эффективней. По-моему, в книге даже был график. Ребята — сами виноваты. Ваше решение лучше по всем критериям! Только if — это не «совсем не ООПшный подход». ООП не запрещает в логике класса использовать условие. Оно просто говорит, что данный подход немного менее очевидный и понятие, лежащее в основе данного условия мы намеренно делаем менее явным и прячем от взора разработчика. Если окажется, что оно было важным — то epic fail. Если более 2х лет нам на него было начихать — okay.
Хочу ещё прокомментировать один момент. Вы чуточку не правы про усложнение или неусложнение системы. Наплодив больше классов, мы увеличиваем количественную сложность системы. Да, классов больше. Качественная сложность может даже наоборот снижаться. У нас же есть мощные инструменты — абстракция и инкапсуляция. Ну и что, что за реализацией данного интерфейса лежат ещё 2 класса и куча условной логики. Мне, как клиенту данного кода — жить прекрасно и шоколадно. А разработчику данного кода — что 1 класс, что 2, что 3 — по сути, равноценно. ООП позволило нам разбить программу на подобласти и под-подобласти, в каждой из которой мир просто, понятен и пушист. А то, что в сумме это на самом деле робот для убийства всех человеков — ну, okay :))
У меня вот авто — Subaru. Считается, что она позволяет ездить быстрее 80% остальных авто. У меня нет к ней претензий, потому что хотя велик соблазн почудить, особенно зимой, я включаю мозг и так не делаю! Несколько раз (месяцев) потренировался на закрытой площадке и действительно, когда необходимо — я могу на ней ездить быстрее остальных.