Здравствуйте, Enomay, Вы писали:
E>>>получили общую сумму покупок за последний месяц и передали доменной модели. G>>Где получили? Кто получили?
E>тот, кто обращается к доменной модели.
E>>>так же эту сумму можно получить из объекта самого покупателя. G>>Каким образом? Выполнить запрос к хранилищу? Покупатель будет иметь ссылку на repository?
E>покупатель будет сформирован с полным набором необходимых данных при помощи доменного сервиса.
Да, при помощи сервиса, а сущность "покупателя" будет DTO. Это уже похоже на нормальный дизайн.
А он соотвествует DDD?
G>>Или ты предложишь циклом ходить по orders, загружая всю историю заказов в память? и выполняя SELECT N+1
E>если доменная логика потребует проходиться циклом по ордерам, то так и будет. E>и да, для этого необходимое кол-во ордеров будет загружено в память. E>и да, вероятно будет select n+1. E>это криминально? в бизнес приложениях — нет. в высоконагруженном сайте? возможно.
Значит DDD позволяет делать только тормозящее говно
Что и требовалось доказать.
Шучу конечно, но ощущение складывается именно такое.
E>>>всё зависит от организации модели. G>>Ок, покажи как эффективно организовать модель в таком случае.
E>нужно исходить из задачи. а не абстрактного выдуманного примера.
Расчет скидки — не выдуманный пример.
E>и эффективная модель в каждом отдельном случаи будет различаться.
Представь что такой же код находится внутри CRM, где для каждого кастомера сотни заказов и десятки тысяч позиций.
E>>>ты их не видишь. другие их видят. не заморачивайся. возможно это придет, со временем. а возможно и нет. G>>Так ты их назови хотя бы, а то даже с этим проблемы возникают. E>преимущества в организации слоя бизнес логики, который отражает действительную проблему.
Так в чем это преимущество?
Ты сейчас пытаешься мне показать в случая с бухгалтерией построение слоя бизнес-логики, который как раз действительные проблемы не отражает.
E>>>мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют. G>>Тогда вы делаете программу, которая нужна вам, а не пользователям. G>>А обычно наоборот, слушают заказчиков\экспертов\пользователей. E>тебе так кажется.
Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.
E>>>DDD не имеет отношения к построению отчетов, точнее даже, обычных выборок. G>>То есть не имеет отношение к домену (той самой предметной области о которой тебе скажут бухгалтеры).
E>отображение отчета какого либо отчета, совершенно никак не влияет на алгоритм расчета зарплат, под который мы делаем доменную модель, а значит, в данном случае, это нас не интересует.
А я не говорю про отображение, я говорю про получение данных. Баланс может и не отображаться, а сразу отправляться в налоговую.
E>>>ценность DDD в организации и построении бизнес логики. G>>Так получение баланса и других данных для отчетов и есть та логика, которая нужна бизнесу. У тебя другое понимание бизнес-логики? E>бизнесу нужна логика расчета данных, а их получение и отображение — это лишь следствие, и к логике никакого отношения уже не имеет.
Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD?
По сути они все являются выборками определенного вида.
Здравствуйте, gandjustas, Вы писали:
G>Да, при помощи сервиса, а сущность "покупателя" будет DTO. Это уже похоже на нормальный дизайн. G>А он соотвествует DDD?
Абсолютно.
E>>и да, вероятно будет select n+1. E>>это криминально? в бизнес приложениях — нет. в высоконагруженном сайте? возможно. G> G>Значит DDD позволяет делать только тормозящее говно G>Что и требовалось доказать. G>Шучу конечно, но ощущение складывается именно такое.
select n+1 это проблема не ДДД, а предметной области. Ты никуда от неё не денешься.
E>>преимущества в организации слоя бизнес логики, который отражает действительную проблему. G>Так в чем это преимущество?
Преимущество заключается в том, что все операции которые зависят от домена, становятся предельно простыми.
E>>>>мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют. G>>>Тогда вы делаете программу, которая нужна вам, а не пользователям. G>>>А обычно наоборот, слушают заказчиков\экспертов\пользователей. E>>тебе так кажется. G>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.
С таким подходом можно делать только хилые продукты. Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг
G>Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD?
Тебе покажется странным, но ДДД очень сильно похоже на то, что на этом форуме называется "функциональный дизайн".
Здравствуйте, Ikemefula, Вы писали:
E>>>и да, вероятно будет select n+1. E>>>это криминально? в бизнес приложениях — нет. в высоконагруженном сайте? возможно. G>> G>>Значит DDD позволяет делать только тормозящее говно G>>Что и требовалось доказать. G>>Шучу конечно, но ощущение складывается именно такое.
I>select n+1 это проблема не ДДД, а предметной области. Ты никуда от неё не денешься.
Полнейший бред. select n+1 это проблема реализации, когда для получения дочерних сущностей необходимо выполнять по одному запросу в базу (удаленному вызову) для каждой родительской. Если написать один запрос, который получает все данные, то это работает на порядок эффективнее.
Причем domain model по фаулеру и lazy load (как раз то что показывает эванс и другие апологеты DDD) подталкивают писать код, который делает select N+1
E>>>преимущества в организации слоя бизнес логики, который отражает действительную проблему. G>>Так в чем это преимущество? I>Преимущество заключается в том, что все операции которые зависят от домена, становятся предельно простыми.
За счет чего? Приведи пример.
E>>>>>мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют. G>>>>Тогда вы делаете программу, которая нужна вам, а не пользователям. G>>>>А обычно наоборот, слушают заказчиков\экспертов\пользователей. E>>>тебе так кажется. G>>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей. I>С таким подходом можно делать только хилые продукты. Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг
Ты хочешь сказать что можно сделать хороший продукт не учитывая пожелания пользователей?
G>>Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD? I>Тебе покажется странным, но ДДД очень сильно похоже на то, что на этом форуме называется "функциональный дизайн".
Вполне может быть что это так, вот только об этом никто не говорит. Или у тебя есть ссылки на подобные высказывания со стороны апологетов DDD?
G>Да, при помощи сервиса, а сущность "покупателя" будет DTO. Это уже похоже на нормальный дизайн. G>А он соотвествует DDD?
сущность покупателя будет иметь поведение. это соответствует DDD.
G>>>Или ты предложишь циклом ходить по orders, загружая всю историю заказов в память? и выполняя SELECT N+1
G>Значит DDD позволяет делать только тормозящее говно G>Что и требовалось доказать. G>Шучу конечно, но ощущение складывается именно такое.
DDD не предназначено для хоумпейджей, форумов, и в принципе, интернет магазинов. эта методология, как и всё остальное, не является серебряной пулей, и не может решать всех задач. но там, где это необходимо, DDD себя отлично показывает.
Эванс, между прочим, об этом говорил.
E>>нужно исходить из задачи. а не абстрактного выдуманного примера. G>Расчет скидки — не выдуманный пример.
в этом нет ничего сложного даже применяя DDD методологию.
E>>и эффективная модель в каждом отдельном случаи будет различаться. G>Представь что такой же код находится внутри CRM, где для каждого кастомера сотни заказов и десятки тысяч позиций.
не представляю, потому что нет ни условий, ни задачи. значит представлять нечего.
а для каждой конкретно задачи, существует отдельное, и не одно, решение.
G>Так в чем это преимущество? G>Ты сейчас пытаешься мне показать в случая с бухгалтерией построение слоя бизнес-логики, который как раз действительные проблемы не отражает.
преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение.
это же очевидно.
но я тебе уже советовал не заморачиваться, а продолжать использовать процедурный подход. он больше тебе подходит.
E>>тебе так кажется. G>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.
DDD методология совершенно не обходит стороной пожелания пользователей. а наоборот. работает с ними на одном языке.
а ты что-то опять путаешь.
E>>отображение отчета какого либо отчета, совершенно никак не влияет на алгоритм расчета зарплат, под который мы делаем доменную модель, а значит, в данном случае, это нас не интересует. G>А я не говорю про отображение, я говорю про получение данных. Баланс может и не отображаться, а сразу отправляться в налоговую.
получение данных — это лишь запрос в базу. сами данные при этом не меняются. а значит никакой логики в этом действии нет.
E>>бизнесу нужна логика расчета данных, а их получение и отображение — это лишь следствие, и к логике никакого отношения уже не имеет. G>Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD? G>По сути они все являются выборками определенного вида.
они могут быть чем угодно.
как выборками, в твоём случаи,
так и просто полем объекта, которое изменяется каждый раз с приходом/уходом денег. соответственно нам нет необходимости пересчитывать баланс каждый раз. мы можем использовать готовое значение в нашей модели. проще говоря, для примера, это будет состояние объекта "баланс".
G>select n+1 это проблема реализации, когда для получения дочерних сущностей необходимо выполнять по одному запросу в базу (удаленному вызову) для каждой родительской.
именно так. но никто, совершенно никто, не мешает делать выборку с join'ами, а после использовать её в DDD. одно другого совершенно не исключает.
Здравствуйте, Enomay, Вы писали:
E>DDD не предназначено для хоумпейджей, форумов, и в принципе, интернет магазинов. эта методология, как и всё остальное, не является серебряной пулей, и не может решать всех задач. но там, где это необходимо, DDD себя отлично показывает. E>Эванс, между прочим, об этом говорил.
Да, но они и другие не говорят для чего предназначен DDD. Потому что чем сложнее предметная область, там больше будет в ней выборок, для которых DDD не предназначен. Бухгалтерия — хороший пример.
E>>>нужно исходить из задачи. а не абстрактного выдуманного примера. G>>Расчет скидки — не выдуманный пример.
E>в этом нет ничего сложного даже применяя DDD методологию.
Ну ты уже показал что сделать это по DDD и эффективно нельзя? Или можно?
E>>>и эффективная модель в каждом отдельном случаи будет различаться. G>>Представь что такой же код находится внутри CRM, где для каждого кастомера сотни заказов и десятки тысяч позиций.
E>не представляю, потому что нет ни условий, ни задачи. значит представлять нечего. E>а для каждой конкретно задачи, существует отдельное, и не одно, решение.
Так задача простая: для расчета скидки покупателя надо получить сумму покупок без скидок за последний месяц.
G>>Так в чем это преимущество? G>>Ты сейчас пытаешься мне показать в случая с бухгалтерией построение слоя бизнес-логики, который как раз действительные проблемы не отражает.
E>преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение. E>это же очевидно. E>но я тебе уже советовал не заморачиваться, а продолжать использовать процедурный подход. он больше тебе подходит.
Что значит "красивом и структурированом"? Это в каких цифрах выражается, хотябы косвенно?
Кроме того "красивый и структурированный" ОО-код может вести к проблемам быстродейтсвия, это ты и сам показал.
Тогда в чем преимущество "красивости и структурированности"?
E>>>тебе так кажется. G>>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей.
E>DDD методология совершенно не обходит стороной пожелания пользователей. а наоборот. работает с ними на одном языке. E>а ты что-то опять путаешь.
Так ты мне доказывал что не надо учитывать "неудобные для DDD" требования пользователей. Как учесть требования получения в программе остатков и оборов по счетам для бухгалтерии? Ведь остатки и обороты это не сущности, а наборы данных.
E>>>отображение отчета какого либо отчета, совершенно никак не влияет на алгоритм расчета зарплат, под который мы делаем доменную модель, а значит, в данном случае, это нас не интересует. G>>А я не говорю про отображение, я говорю про получение данных. Баланс может и не отображаться, а сразу отправляться в налоговую.
E>получение данных — это лишь запрос в базу. сами данные при этом не меняются. а значит никакой логики в этом действии нет.
То есть "логика" это изменение данных? А если частью логики являются такие запросы?
Например те же самые скидки.
E>>>бизнесу нужна логика расчета данных, а их получение и отображение — это лишь следствие, и к логике никакого отношения уже не имеет. G>>Так я с этого и начал. Вот есть у бухгалтеров баланс, это не балансовая ведомость, а некоторые данные, соотвествующие определенным правилам. еще есть обороты, остатки — тоже наборы данных, формирующиеся по определенным правилам. Как и правильно отражать в программе с точки зрения DDD? G>>По сути они все являются выборками определенного вида.
E>они могут быть чем угодно. E>как выборками, в твоём случаи, E>так и просто полем объекта, которое изменяется каждый раз с приходом/уходом денег. соответственно нам нет необходимости пересчитывать баланс каждый раз. мы можем использовать готовое значение в нашей модели. проще говоря, для примера, это будет состояние объекта "баланс".
Это понятно, а как это будет выражаться в коде с точки зрения DDD?
Здравствуйте, Enomay, Вы писали:
G>>select n+1 это проблема реализации, когда для получения дочерних сущностей необходимо выполнять по одному запросу в базу (удаленному вызову) для каждой родительской.
E>именно так. но никто, совершенно никто, не мешает делать выборку с join'ами, а после использовать её в DDD. одно другого совершенно не исключает.
А куда эту выборку поместить? Ведь в сущностях иметь ссылку на repository — моветон, а если в сервисы, то получится anemic.
E>>Эванс, между прочим, об этом говорил. G>Да, но они и другие не говорят для чего предназначен DDD. Потому что чем сложнее предметная область, там больше будет в ней выборок, для которых DDD не предназначен. Бухгалтерия — хороший пример.
выборка не есть логика.
проблема совершенно не в DDD, а в непонимании тобой это методологии.
в очередной раз советую вернутся к процедурному программированию и не забивать голову лишними вещами.
E>>в этом нет ничего сложного даже применяя DDD методологию. G>Ну ты уже показал что сделать это по DDD и эффективно нельзя? Или можно?
конечно можно.
E>>не представляю, потому что нет ни условий, ни задачи. значит представлять нечего. E>>а для каждой конкретно задачи, существует отдельное, и не одно, решение. G>Так задача простая: для расчета скидки покупателя надо получить сумму покупок без скидок за последний месяц.
решение не менее простое.
E>>преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение. E>>это же очевидно. E>>но я тебе уже советовал не заморачиваться, а продолжать использовать процедурный подход. он больше тебе подходит. G>Что значит "красивом и структурированом"? Это в каких цифрах выражается, хотябы косвенно?
не все можно выразить цифрами.
G>Кроме того "красивый и структурированный" ОО-код может вести к проблемам быстродейтсвия, это ты и сам показал.
иногда. но в большинстве случаев он легче масштабируется, что решает проблемы быстродействия.
G>Тогда в чем преимущество "красивости и структурированности"?
в том же, в чем и любого другого хорошего кода, конечно же.
неужели это так не очевидно?
E>>DDD методология совершенно не обходит стороной пожелания пользователей. а наоборот. работает с ними на одном языке. E>>а ты что-то опять путаешь. G>Так ты мне доказывал что не надо учитывать "неудобные для DDD" требования пользователей. Как учесть требования получения в программе остатков и оборов по счетам для бухгалтерии? Ведь остатки и обороты это не сущности, а наборы данных.
ты глупости говоришь.
я не доказывал, но пытался дать понять, что те вещи, которые не требуются при разработке модели, нужно опускать.
и остатки и обороты можно представить сущностями, пользуясь DDD методологией. но ты идешь от обратного, потому для тебя это наборы данных, и DDD скорее всего, как и ООП в целом, ты понять не сможешь, так как мыслишь с "процедурной" точки зрения.
E>>получение данных — это лишь запрос в базу. сами данные при этом не меняются. а значит никакой логики в этом действии нет. G>То есть "логика" это изменение данных? А если частью логики являются такие запросы? G>Например те же самые скидки.
для расчета скидки, нам нужно знать, делать её, или нет. как мы получим этот признак, нас не итересует.
ты сделаешь выборку в очередной раз, и передашь это значение.
кто-то другой возьмет готовый признак из объекта покупателя, который туда заносится после каждой совершенной покупки, и не требует пересчета каждый раз, как в твоём случае.
вариантов достаточное кол-во.
и ни один из них не делает DDD лучше или хуже.
E>>они могут быть чем угодно. E>>как выборками, в твоём случаи, E>>так и просто полем объекта, которое изменяется каждый раз с приходом/уходом денег. соответственно нам нет необходимости пересчитывать баланс каждый раз. мы можем использовать готовое значение в нашей модели. проще говоря, для примера, это будет состояние объекта "баланс". G>Это понятно, а как это будет выражаться в коде с точки зрения DDD?
так, как ты это реализуешь.
самые простые 2 варианта, на которые собственно должно было натолкнуть предыдущее предложение.
а) сервис расчитывает баланс и передает его доменному объекту при его создании, после чего тот выполняет свою логику с учетом этих данных
б) загружаем доменный объект из базы при помощи ORM и передаем ему управление.
оба варианта очень похожи, и по сути одинаковы, различия лишь в реализации.
и того имеем все данные и логику в доменной модели, что не противоречит DDD.
E>>именно так. но никто, совершенно никто, не мешает делать выборку с join'ами, а после использовать её в DDD. одно другого совершенно не исключает.
G>А куда эту выборку поместить? Ведь в сущностях иметь ссылку на repository — моветон, а если в сервисы, то получится anemic.
anemic получится лишь в том случаи, если в модели не будет логики, а вся она будет в сервисах. в данном же случаи, в сервисах нет бизнес логики. там только загрузка данных. вся логика в модели.
впрочем, по DDD, доменные сервисы вполне себе могут нести эту самую логику, если так будет необходимо. в том числе и подгрузку данных. а сервисы можно вызывать из доменных объектов.
впрочем, о том, что использования репозиториев в объектах домена — моветон, выдумки, ведь ни Фаулер, ни Эванс, об этом ничего не пишут.
а репозиторий не более чем коллекция, с точки зрения использования. а ведь коллекции нам никто не запрещает юзать в домене.
Здравствуйте, Enomay, Вы писали:
E>>>Эванс, между прочим, об этом говорил. G>>Да, но они и другие не говорят для чего предназначен DDD. Потому что чем сложнее предметная область, там больше будет в ней выборок, для которых DDD не предназначен. Бухгалтерия — хороший пример.
E>выборка не есть логика.
То есть логика только в изменении данных?
Тогда задача получения суммы покупок для расчета скидки не является логикой, а сам расчет скидки является?
Какая-то фейерическая глупость чтобы оправдать проблемы.
E>проблема совершенно не в DDD, а в непонимании тобой это методологии.
Ну так попытайся объяснить в чем состоит методология DDD.
E>>>в этом нет ничего сложного даже применяя DDD методологию. G>>Ну ты уже показал что сделать это по DDD и эффективно нельзя? Или можно? E>конечно можно.
Каким образом?
E>>>не представляю, потому что нет ни условий, ни задачи. значит представлять нечего. E>>>а для каждой конкретно задачи, существует отдельное, и не одно, решение. G>>Так задача простая: для расчета скидки покупателя надо получить сумму покупок без скидок за последний месяц. E>решение не менее простое.
Покажи его, чтобы оно было DDD и при этом достаточно эффективно.
E>>>преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение. E>>>это же очевидно. E>>>но я тебе уже советовал не заморачиваться, а продолжать использовать процедурный подход. он больше тебе подходит. G>>Что значит "красивом и структурированом"? Это в каких цифрах выражается, хотябы косвенно? E>не все можно выразить цифрами.
Если ты не можешь выразить цифрами значит в этом нет реального value.
G>>Кроме того "красивый и структурированный" ОО-код может вести к проблемам быстродейтсвия, это ты и сам показал. E>иногда. но в большинстве случаев он легче масштабируется, что решает проблемы быстродействия.
Как раз в большинстве случаев ОО-код хуже масштабируется. Потому что:
1) Надо таскать identity
2) Надо материализовывать объекты потому что поведение внутри объектов
Очень хорошо масштабируется SOA, причем как вверх, так и вниз. Там как раз отказ от identity и создания объектов, там только сервисы и данные (DTO).
G>>Тогда в чем преимущество "красивости и структурированности"?
E>в том же, в чем и любого другого хорошего кода, конечно же. E>неужели это так не очевидно?
Совсем не очевидно, потому что понятие "красивости" у каждого сильно свое и никак не коррелирует с качеством кода (объемом, плотностью багов, сложностью поддержки итп).
E>>>DDD методология совершенно не обходит стороной пожелания пользователей. а наоборот. работает с ними на одном языке. E>>>а ты что-то опять путаешь. G>>Так ты мне доказывал что не надо учитывать "неудобные для DDD" требования пользователей. Как учесть требования получения в программе остатков и оборов по счетам для бухгалтерии? Ведь остатки и обороты это не сущности, а наборы данных.
E>ты глупости говоришь.
E>>>эксперты говорят на языке объектов.
G>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.
E>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
Ты сказал что то что говорят эксперты не надо рассматривать при построении модели.
E>я не доказывал, но пытался дать понять, что те вещи, которые не требуются при разработке модели, нужно опускать.
Если о чем-то говорит эксперт, то это должно быть в модели, потому что иначе не будет Ubiquitous Language, к которому стремится DDD.
Иначе вам придется переучивать эксперта, а это сложно.
E>и остатки и обороты можно представить сущностями, пользуясь DDD методологией. но ты идешь от обратного, потому для тебя это наборы данных, и DDD скорее всего, как и ООП в целом, ты понять не сможешь, так как мыслишь с "процедурной" точки зрения.
Ну покажи как их представить сущностями и как с ними работать в программе. (у тебя получится anemic)
E>>>получение данных — это лишь запрос в базу. сами данные при этом не меняются. а значит никакой логики в этом действии нет. G>>То есть "логика" это изменение данных? А если частью логики являются такие запросы? G>>Например те же самые скидки.
E>для расчета скидки, нам нужно знать, делать её, или нет. как мы получим этот признак, нас не итересует.
Нам важна величина скидки, а не вопрос делать её или нет.
E>>>они могут быть чем угодно. E>>>как выборками, в твоём случаи, E>>>так и просто полем объекта, которое изменяется каждый раз с приходом/уходом денег. соответственно нам нет необходимости пересчитывать баланс каждый раз. мы можем использовать готовое значение в нашей модели. проще говоря, для примера, это будет состояние объекта "баланс". G>>Это понятно, а как это будет выражаться в коде с точки зрения DDD?
E>так, как ты это реализуешь. E>самые простые 2 варианта, на которые собственно должно было натолкнуть предыдущее предложение. E>а) сервис расчитывает баланс и передает его доменному объекту при его создании, после чего тот выполняет свою логику с учетом этих данных
Браво, расчет скидки размазан по двум объектам.
E>б) загружаем доменный объект из базы при помощи ORM и передаем ему управление.
Какой объект, нет объекта "скидка", потому что она требует расчета на момент покупки.
E>оба варианта очень похожи, и по сути одинаковы, различия лишь в реализации.
И оба они хуже, чем помещение всего алгоритма расчета в сервис.
E>и того имеем все данные и логику в доменной модели, что не противоречит DDD.
Она становится размазанной по нескольким объектам. Материализация объектов избыточна получается в данном случае, она нужна только чтобы вызывать логику. Тогда логику лучше поместить вне этих объектов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Enomay, Вы писали:
E>>и того имеем все данные и логику в доменной модели, что не противоречит DDD. G>Она становится размазанной по нескольким объектам. Материализация объектов избыточна получается в данном случае, она нужна только чтобы вызывать логику. Тогда логику лучше поместить вне этих объектов.
Мало материализовать, надо еще и напичкать ссылками на используемые в логике объекта сервисы, репозитории...
E>>выборка не есть логика. G>То есть логика только в изменении данных?
вывод списка строк не есть логика.
G>Тогда задача получения суммы покупок для расчета скидки не является логикой, а сам расчет скидки является?
получение суммы покупок — это извлечение одного поля из базы данных.
это логика?
G>Какая-то фейерическая глупость чтобы оправдать проблемы.
какие проблемы? у меня нет проблем. для меня DDD вполне эффективная методология.
для тебя нет. но ты пытаешься, пыжишься. для чего только, не ясно.
E>>проблема совершенно не в DDD, а в непонимании тобой это методологии. G>Ну так попытайся объяснить в чем состоит методология DDD.
Эванс пытался. если у него не удалось, то у меня не выйдет тем более.
да и незачем мне этим заниматься.
G>Каким образом? G>Покажи его, чтобы оно было DDD и при этом достаточно эффективно.
я уже приводил пару возможных примеров.
E>>не все можно выразить цифрами. G>Если ты не можешь выразить цифрами значит в этом нет реального value.
ты наверное один из тех, кто эффективность разработчика меряет кол-вом строк кода?
G>Как раз в большинстве случаев ОО-код хуже масштабируется. Потому что: G>1) Надо таскать identity G>2) Надо материализовывать объекты потому что поведение внутри объектов
какое это имеет отношение к масштабированию?
G>Очень хорошо масштабируется SOA, причем как вверх, так и вниз. Там как раз отказ от identity и создания объектов, там только сервисы и данные (DTO).
вертикальное масштабирование имеет предел.
E>>в том же, в чем и любого другого хорошего кода, конечно же. E>>неужели это так не очевидно? G>Совсем не очевидно, потому что понятие "красивости" у каждого сильно свое и никак не коррелирует с качеством кода (объемом, плотностью багов, сложностью поддержки итп).
разве я говорил о эстетической красоте?
конечно же имелось ввиду простота поддержки и расширения существующего кода. а для этого он должен быть не похож на говно.
E>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели. G>Ты сказал что то что говорят эксперты не надо рассматривать при построении модели.
ты опять говоришь глупости и перевираешь мои слова. перечитай еще раз про дистилляцию.
E>>я не доказывал, но пытался дать понять, что те вещи, которые не требуются при разработке модели, нужно опускать. G>Если о чем-то говорит эксперт, то это должно быть в модели, потому что иначе не будет Ubiquitous Language, к которому стремится DDD. G>Иначе вам придется переучивать эксперта, а это сложно.
прочти книгу Эванса, и убедись в том, что написанное тобой лишь плод твоего воображения.
он там приводит отличные примеры того, когда они накосячили из-за того, что слушали всё подряд.
E>>и остатки и обороты можно представить сущностями, пользуясь DDD методологией. но ты идешь от обратного, потому для тебя это наборы данных, и DDD скорее всего, как и ООП в целом, ты понять не сможешь, так как мыслишь с "процедурной" точки зрения. G>Ну покажи как их представить сущностями и как с ними работать в программе. (у тебя получится anemic)
у тебя получится anemic, у меня будет домен.
E>>для расчета скидки, нам нужно знать, делать её, или нет. как мы получим этот признак, нас не итересует. G>Нам важна величина скидки, а не вопрос делать её или нет.
это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку.
в обоих случаях подход и суть та же.
E>>а) сервис расчитывает баланс и передает его доменному объекту при его создании, после чего тот выполняет свою логику с учетом этих данных G>Браво, расчет скидки размазан по двум объектам.
нет, расчет скидки реализуется одним объектом.
E>>б) загружаем доменный объект из базы при помощи ORM и передаем ему управление. G>Какой объект, нет объекта "скидка", потому что она требует расчета на момент покупки.
ты очень невнимателен. а ведь я уже писал.
проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем.
можешь хранить его целиком, можешь расчитывать на момент получения покупателя. (в твоём случае ты ведь и будешь его всегда считать).
она же и будет использоваться для расчета скидки этого покупателя.
E>>оба варианта очень похожи, и по сути одинаковы, различия лишь в реализации. G>И оба они хуже, чем помещение всего алгоритма расчета в сервис.
хуже для тебя. потому что процедурный стиль программирования тебе ближе.
в целом же, с точки зрения ООП, это правильная реализация. а DDD как раз более чем придерживается ООП парадигмы.
E>>и того имеем все данные и логику в доменной модели, что не противоречит DDD. G>Она становится размазанной по нескольким объектам. Материализация объектов избыточна получается в данном случае, она нужна только чтобы вызывать логику. Тогда логику лучше поместить вне этих объектов.
для того что бы наложить какую-то логику на что-то, тебе это что-то нужно получить.
в твоём случае это будет anemic модель. но её так же придется материализовать.
верно и обратное, что в DDD не всегда и всё необходимо материализовывать. при необходимости, мы без проблем можем вызвать сервис, который сделает update с условием.
насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация.
Здравствуйте, Enomay, Вы писали:
E>>>именно так. но никто, совершенно никто, не мешает делать выборку с join'ами, а после использовать её в DDD. одно другого совершенно не исключает.
G>>А куда эту выборку поместить? Ведь в сущностях иметь ссылку на repository — моветон, а если в сервисы, то получится anemic.
E>anemic получится лишь в том случаи, если в модели не будет логики, а вся она будет в сервисах. в данном же случаи, в сервисах нет бизнес логики. там только загрузка данных. вся логика в модели. E>впрочем, по DDD, доменные сервисы вполне себе могут нести эту самую логику, если так будет необходимо. в том числе и подгрузку данных. а сервисы можно вызывать из доменных объектов.
Вот, прекрасно. Получяется схема
[сервисы -> доменные объекты -> доменные сервисы] причем последние как раз не содержат данных и обращаются к данным доменных объектов
тогда лучше убрать лишние уровни косвенности и получить
[сервисы -> доменные сервисы], сервисы будут получать данные из базы и передавать доменным сервисам
тогда в большинстве случаев можно поместить код доменных сервисов в сами сервисы, а вместо получения доменных объектов получать проекции из базы, содержащие ровно столько данных сколько необходимо. Таким образом часть вычислений можно также перенести в БД, заставляя запросы делать агрегацию данных. И это будет максимально эффективным решением.
E>впрочем, о том, что использования репозиториев в объектах домена — моветон, выдумки, ведь ни Фаулер, ни Эванс, об этом ничего не пишут.
Фаулер пишет, почитай внимательно главу про Domain Model в PoEAA
E>а репозиторий не более чем коллекция, с точки зрения использования. а ведь коллекции нам никто не запрещает юзать в домене.
Ага, добавляй ссылки на репозитарии к доменным объектам, получай ball-of-mud архитектуру.
Здравствуйте, gandjustas, Вы писали:
I>>select n+1 это проблема не ДДД, а предметной области. Ты никуда от неё не денешься. G>Полнейший бред. select n+1 это проблема реализации, когда для получения дочерних сущностей необходимо выполнять по одному запросу в базу (удаленному вызову) для каждой родительской. Если написать один запрос, который получает все данные, то это работает на порядок эффективнее.
То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ? Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий.
Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции.
I>>Преимущество заключается в том, что все операции которые зависят от домена, становятся предельно простыми. G>За счет чего? Приведи пример.
См. пример про смешение цветов в книге Эванса.
G>>>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей. I>>С таким подходом можно делать только хилые продукты. Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг G>Ты хочешь сказать что можно сделать хороший продукт не учитывая пожелания пользователей?
Все что я хотел сказать, я уже сказал : "Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг"
Хочешь опровергнуть это, покажи пример грузового-легкового минивена-родстера
I>>Тебе покажется странным, но ДДД очень сильно похоже на то, что на этом форуме называется "функциональный дизайн". G>Вполне может быть что это так, вот только об этом никто не говорит. Или у тебя есть ссылки на подобные высказывания со стороны апологетов DDD?
Здравствуйте, Enomay, Вы писали:
E>>>выборка не есть логика. G>>То есть логика только в изменении данных?
E>вывод списка строк не есть логика.
А я не говорил про вывод, я говорю что выборка нужна для расчета суммы скидки, сами строки никуда не выводятся.
G>>Тогда задача получения суммы покупок для расчета скидки не является логикой, а сам расчет скидки является?
E>получение суммы покупок — это извлечение одного поля из базы данных. E>это логика?
Не одного, а суммы множества полей по определенным критериям. Хранить ты его не можешь, как как нужна сумма за месяц с текущего момента.
G>>Какая-то фейерическая глупость чтобы оправдать проблемы.
E>какие проблемы? у меня нет проблем. для меня DDD вполне эффективная методология.
В чем её эффективность? Есть выражение этой эффективности в цифрах? Я пока вижу проблемы с быстродейтсвием.
E>для тебя нет. но ты пытаешься, пыжишься. для чего только, не ясно.
Эффективность или есть или её нет, не бывает что для кого-то она есть, а для другого нет.
E>>>проблема совершенно не в DDD, а в непонимании тобой это методологии. G>>Ну так попытайся объяснить в чем состоит методология DDD. E>Эванс пытался. если у него не удалось, то у меня не выйдет тем более. E>да и незачем мне этим заниматься.
То есть ты не знаешь в чем заключается методология DDD?
G>>Каким образом? G>>Покажи его, чтобы оно было DDD и при этом достаточно эффективно. E>я уже приводил пару возможных примеров.
Оба гораздо менее эффективны чем могли бы быть.
E>>>не все можно выразить цифрами. G>>Если ты не можешь выразить цифрами значит в этом нет реального value. E>ты наверное один из тех, кто эффективность разработчика меряет кол-вом строк кода?
Нет, я один из тех для кого эффективность разработчика меряется количеством заработанных денег. Причем если зарабатыввает много денег, но пишет мало кода то это очень хорошо.
G>>Как раз в большинстве случаев ОО-код хуже масштабируется. Потому что: G>>1) Надо таскать identity G>>2) Надо материализовывать объекты потому что поведение внутри объектов E>какое это имеет отношение к масштабированию?
Самое прямое.
G>>Очень хорошо масштабируется SOA, причем как вверх, так и вниз. Там как раз отказ от identity и создания объектов, там только сервисы и данные (DTO).
E>вертикальное масштабирование имеет предел.
Я не про масштабирование ресурсов, я про масштабрирование задачи. SOA-подход работает как на простой задаче, выполняющийся на одной машине, так и в сильно распределенной среде. В отличие от ООП. Объекты распределять крайне неэффективно.
E>>>в том же, в чем и любого другого хорошего кода, конечно же. E>>>неужели это так не очевидно? G>>Совсем не очевидно, потому что понятие "красивости" у каждого сильно свое и никак не коррелирует с качеством кода (объемом, плотностью багов, сложностью поддержки итп).
E>разве я говорил о эстетической красоте? E>конечно же имелось ввиду простота поддержки и расширения существующего кода. а для этого он должен быть не похож на говно.
В среднем anemic кода получается меньше, чем rich при той же задаче. О какой простоте поддержки ты говоришь?
E>>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели. G>>Ты сказал что то что говорят эксперты не надо рассматривать при построении модели. E>ты опять говоришь глупости и перевираешь мои слова. перечитай еще раз про дистилляцию.
Читал, и что? Дистиллируй сколько хочешь, но если эксперт говорит что-то, то это надо или учитывать в модели или переучивать эксперта.
E>>>я не доказывал, но пытался дать понять, что те вещи, которые не требуются при разработке модели, нужно опускать. G>>Если о чем-то говорит эксперт, то это должно быть в модели, потому что иначе не будет Ubiquitous Language, к которому стремится DDD. G>>Иначе вам придется переучивать эксперта, а это сложно.
E>прочти книгу Эванса, и убедись в том, что написанное тобой лишь плод твоего воображения. E>он там приводит отличные примеры того, когда они накосячили из-за того, что слушали всё подряд.
Думаешь если не слушать все вероятность ошибок уменьшится? Думаешь если ты при построении модели для бухгалтерии отбросишь обороты и потом совершенно случайно не сделаешь их, то пользователи останутся довольны?
E>>>и остатки и обороты можно представить сущностями, пользуясь DDD методологией. но ты идешь от обратного, потому для тебя это наборы данных, и DDD скорее всего, как и ООП в целом, ты понять не сможешь, так как мыслишь с "процедурной" точки зрения. G>>Ну покажи как их представить сущностями и как с ними работать в программе. (у тебя получится anemic) E>у тебя получится anemic, у меня будет домен.
Приведи пример, посмотрим.
E>>>для расчета скидки, нам нужно знать, делать её, или нет. как мы получим этот признак, нас не итересует. G>>Нам важна величина скидки, а не вопрос делать её или нет.
E>это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку.
Это как раз важно, откуда мы передадим это число?
E>проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем.
Нельзя, потому что требуется сумма покупок за последний месяц, то есть вычисление на момент покупки, хранить значение ты не сможешь.
E>>>оба варианта очень похожи, и по сути одинаковы, различия лишь в реализации. G>>И оба они хуже, чем помещение всего алгоритма расчета в сервис. E>хуже для тебя. потому что процедурный стиль программирования тебе ближе. E>в целом же, с точки зрения ООП, это правильная реализация. а DDD как раз более чем придерживается ООП парадигмы.
То есть единственная цель "придерживаться ООП парадигмы" чего бы оно не стоило?
E>>>и того имеем все данные и логику в доменной модели, что не противоречит DDD. G>>Она становится размазанной по нескольким объектам. Материализация объектов избыточна получается в данном случае, она нужна только чтобы вызывать логику. Тогда логику лучше поместить вне этих объектов. E>для того что бы наложить какую-то логику на что-то, тебе это что-то нужно получить. E>в твоём случае это будет anemic модель. но её так же придется материализовать.
В данном случае мне надо получить число. Ровно одно число, и все. Мне не нужен объект кастомера со всеми его свойствами чтобы считать скидку.
E>верно и обратное, что в DDD не всегда и всё необходимо материализовывать. при необходимости, мы без проблем можем вызвать сервис, который сделает update с условием.
Да, и это уже будет anemic, потому что есть сервис и нет "доменных объектов".
E>насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация.
В SOLID куча других принципов, да и за пределами SOLID тоже, и DDD, как его описывает эванс, многое нарушает.
E>>получение суммы покупок — это извлечение одного поля из базы данных. E>>это логика? G>Не одного, а суммы множества полей по определенным критериям.
да это не важно в общем-то. доменная модель имеет эти сведения.
G>Хранить ты его не можешь, как как нужна сумма за месяц с текущего момента.
в сиквеле, нет, в документной базе, без проблем в общем-то.
G>>>Какая-то фейерическая глупость чтобы оправдать проблемы.
E>>какие проблемы? у меня нет проблем. для меня DDD вполне эффективная методология. G>В чем её эффективность? Есть выражение этой эффективности в цифрах? Я пока вижу проблемы с быстродейтсвием.
это от того, что ты не понимаешь как это можно применять.
на деле же, это можно развернуть как в масштабируемое приложение, так и пожертвовать быстродействием, если оно нас не волнует.
E>>для тебя нет. но ты пытаешься, пыжишься. для чего только, не ясно. G>Эффективность или есть или её нет, не бывает что для кого-то она есть, а для другого нет.
человек умеет работать каким-то инструментом.
есть другой инструмент, более высокотехнологический, который позволяет повысить эффективность в 2 раза.
но человек не умеет им пользоваться, и получает производительность в 2 раза ниже, от производительности своего более простого инструмента.
ясно?
G>То есть ты не знаешь в чем заключается методология DDD?
ты волен считать так, как тебе больше нравится
G>>>Каким образом? G>>>Покажи его, чтобы оно было DDD и при этом достаточно эффективно. E>>я уже приводил пару возможных примеров. G>Оба гораздо менее эффективны чем могли бы быть.
они достаточно эффективны с точки зрения реализации бизнес логики. остальное — технические детали.
G>>>Как раз в большинстве случаев ОО-код хуже масштабируется. Потому что: G>>>1) Надо таскать identity G>>>2) Надо материализовывать объекты потому что поведение внутри объектов E>>какое это имеет отношение к масштабированию? G>Самое прямое.
совершенно никакого. но тебе наверняка виднее.
G>Я не про масштабирование ресурсов, я про масштабрирование задачи. SOA-подход работает как на простой задаче, выполняющийся на одной машине, так и в сильно распределенной среде. В отличие от ООП. Объекты распределять крайне неэффективно.
объекты распределять и не требуется.
более того, в реализацию SOA вполне может лечь ООП. а это значит, что там может быть использован DDD.
G>В среднем anemic кода получается меньше, чем rich при той же задаче. О какой простоте поддержки ты говоришь?
а говорил строками код не меряешь.
но меньше кода, не значит лучше.
E>>ты опять говоришь глупости и перевираешь мои слова. перечитай еще раз про дистилляцию. G>Читал, и что? Дистиллируй сколько хочешь, но если эксперт говорит что-то, то это надо или учитывать в модели или переучивать эксперта.
я уже давно понял почему DDD методология для тебя не эффективна, но ты в очередной раз доказываешь мою правоту.
G>Думаешь если не слушать все вероятность ошибок уменьшится? Думаешь если ты при построении модели для бухгалтерии отбросишь обороты и потом совершенно случайно не сделаешь их, то пользователи останутся довольны?
ты мешаешь всё подряд. у тебя каша в голове.
E>>у тебя получится anemic, у меня будет домен. G>Приведи пример, посмотрим.
ты слишком много хочешь.
примеров, полный гугл.
E>>это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку. G>Это как раз важно, откуда мы передадим это число?
ты в 10 раз задаешь один и тот же вопрос. перечитай тред, ответ там есть.
E>>проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем. G>Нельзя, потому что требуется сумма покупок за последний месяц, то есть вычисление на момент покупки, хранить значение ты не сможешь.
смогу.
E>>хуже для тебя. потому что процедурный стиль программирования тебе ближе. E>>в целом же, с точки зрения ООП, это правильная реализация. а DDD как раз более чем придерживается ООП парадигмы. G>То есть единственная цель "придерживаться ООП парадигмы" чего бы оно не стоило?
цель — использовать преимущества ООП парадигмы при решении задач. а так же DDD методологии.
но для кого-то функциональное программирование кажется лучшим решением. это его право. и это 2 совершенно разных подхода.
G>В данном случае мне надо получить число. Ровно одно число, и все. Мне не нужен объект кастомера со всеми его свойствами чтобы считать скидку.
не вижу никаких проблем что бы при DDD подходе получить 1 число. и ни Фаулер, ни Эванс, этого не запрещают.
E>>верно и обратное, что в DDD не всегда и всё необходимо материализовывать. при необходимости, мы без проблем можем вызвать сервис, который сделает update с условием. G>Да, и это уже будет anemic, потому что есть сервис и нет "доменных объектов".
ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать.
E>>насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация. G>В SOLID куча других принципов, да и за пределами SOLID тоже, и DDD, как его описывает эванс, многое нарушает.
нет, DDD это классическое ООП, и ничего не нарушает.
а вот anemic, в общем-то, не является ООП подходом.
разные реализации. ты используешь процедурный подход, мы ООП.
в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно.
Здравствуйте, Lloyd, Вы писали:
L>Вы не правы, если считаете, что ваша трактовка "по Эвансу" — верна. Если бы я хотел сказать, что для "ДДД годится исключительно рич", я бы так и написал.
Ты даже больше сказал — ДДД это рич
Смотри свои высказывания:
1 "ddd — это не только принцип, но и архитектура с определенным разбиением ..."
2 "примеры, которые он приводит, демонстрируют его мнение о ddd как архитектуре, а там — именно рич-модель"
3 "Если в качестве первоисточника обращаться к эвансу, то ddd — это все-таки рич."
Эванс пишет чуток другое
1 ДДД это принцип, который можно применить к разным архитектурам
2 примеры приведены только для самой популярной модели
3 в книге про ДДД, примеры — рич, но из этого никак не следует, что ДДД это рич.
L>Я же написал, что "Архитектура ДДД по Эвансу — рич", что означет то, и только то, что там написано: есть архитектура ДДД по Эвансу (честно-честно есть, смотрите главы 4-7) и она — рич. Точка.
То есть, ты хотел сказать, что ДДД по Эвансу это ДДД по Эвансу ? Спасибо, Капитан
Здравствуйте, Ikemefula, Вы писали:
L>>Вы не правы, если считаете, что ваша трактовка "по Эвансу" — верна. Если бы я хотел сказать, что для "ДДД годится исключительно рич", я бы так и написал.
I>Ты даже больше сказал — ДДД это рич
Это твои фантазии и только. Все что я писал — это что ddd-архитектура по Эванс — рич. Ничего более.
I>Смотри свои высказывания: I>1 "ddd — это не только принцип, но и архитектура с определенным разбиением ..." I>2 "примеры, которые он приводит, демонстрируют его мнение о ddd как архитектуре, а там — именно рич-модель" I>3 "Если в качестве первоисточника обращаться к эвансу, то ddd — это все-таки рич."
I>Эванс пишет чуток другое
I>1 ДДД это принцип, который можно применить к разным архитектурам
Кэп?
I>2 примеры приведены только для самой популярной модели
Это несомненно делает их не рич, не так ли?
I>3 в книге про ДДД, примеры — рич, но из этого никак не следует, что ДДД это рич.
Да, не следует. Сколько раз мне с этим нужно согласиться, чтобы ты перестал это повторять?
L>>Я же написал, что "Архитектура ДДД по Эвансу — рич", что означет то, и только то, что там написано: есть архитектура ДДД по Эвансу (честно-честно есть, смотрите главы 4-7) и она — рич. Точка.
I>То есть, ты хотел сказать, что ДДД по Эвансу это ДДД по Эвансу ? Спасибо, Капитан
Нет, я хотел сказать (и сказал), что "архитектура ДДД по Эвансу — рич". Но до тебя все никак не дойдет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>select n+1 это проблема не ДДД, а предметной области. Ты никуда от неё не денешься. G>>Полнейший бред. select n+1 это проблема реализации, когда для получения дочерних сущностей необходимо выполнять по одному запросу в базу (удаленному вызову) для каждой родительской. Если написать один запрос, который получает все данные, то это работает на порядок эффективнее.
I>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ?
Да, причем это математически доказано.
I>Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий.
Ни разу он не большой. I>Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции.
Фигня, SQL Server сам такие вычисления легко делает, он для этого и проектировался.
G>>>>Ну конечно, только мне кажется что сделать успешный продукт можно только учитывая пожелания пользователей. I>>>С таким подходом можно делать только хилые продукты. Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг G>>Ты хочешь сказать что можно сделать хороший продукт не учитывая пожелания пользователей?
I>Все что я хотел сказать, я уже сказал : "Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг"
Ну ты просто пытаешься с себя снять ответственность за некоторый класс ошибок — неблагородно.
I>Хочешь опровергнуть это, покажи пример грузового-легкового минивена-родстера
А зачем такая машина нужна? Лучше иметь несколько разных машин.
I>>>Тебе покажется странным, но ДДД очень сильно похоже на то, что на этом форуме называется "функциональный дизайн". G>>Вполне может быть что это так, вот только об этом никто не говорит. Или у тебя есть ссылки на подобные высказывания со стороны апологетов DDD? I>Об этом говорит сам Эванс и этого достаточно
Ну, ссылку, цитату. Я видел обратное.
