J>т.е. из Application Layer нельзя написать код: J>
J>var contactInformation = new ContactInformation(...);
J>repo.Save(contactInformaion);
J>
J>Все изменения нужно делать только через агрегат рут(User): J>
J>var user = userRepository.Load(userId);
J>user.UpdateInformation(userInformation.Info, userInformation.Email);
J>userRepository.Save(user);
J>
J>Бизнес логику желательно писать в самых конечных объектах (Value Objects). J>В моделях валидацию можно рассматривать как инварианты. Проверка того что объекты всегда в правильном состоянии, J>весь остальной код в моделях относится только к бизнес логике. J>Валидация типа J>
J>if(repo.GetUserById(id) != null)
J>{
J> throw new NotFoundException();
J>}
J>
J>будет в Application Layer-e.
Вообще данная логика должна быть в DomainService, зачем app srv. знать про какой-то репо. Выше же сами об этом написали.
Кодом людям нужно помогать!
Re[19]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, #John, Вы писали:
J>У оо больше возможностей по написанию более независимого, модульного кода. J>В процедурном стиле: не используется сокрытие информации(модификаторы доступа), (т.к. поля/свойства всегда public). J>потому может произойти такая ситуация, что код по изменению поля структуры будет раскидан в разных местах проекта/класса, J>а изменение этого поля будет зависеть от разных условий. А код который меняет это поле будет зависеть еще от другого код, J>а тот еще и еще. И когда понадобится добавить новую логику которая будет дополнительно как-то менять поле, J>нам придется вместо того что бы подправить код в одном классе/объекте продебажить пол проекта и найти место куда воткнуть наш код.
Здравствуйте, alexsoff, Вы писали:
A>Я не спорю, что процедурная программа хуже ООП в плане понимания и поддержки, но я хочу сказать, что будущее все-таки за FP стилем, а тут уже Rich Model — очень трудно вписать.
S>GoF — целиком и полностью адаптация ранее использовавшихся практик для функций высших порядков (и не только), функторов и т.п. S>Применение паттерна "Стратегия" можно обнаружить в стандартной процедуре сортировки в "C", в WinAPI и т.п... Остальное так или иначе использовалось за десятки лет до GoF-а в функциональных языках.
А можно примеры? Мне казалось, что GoF больше про декоратор, template method, observer, и, наконец, mvc.
Как это было реализовано в ФП? А главное зачем все это для фп?
Кодом людям нужно помогать!
Re[20]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sharov, Вы писали:
S>Тут хорошая стать и отличная картинка на эту тему -- https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86?gi=40c25922c8e9
По-моему — очередной булшит.
1. В нормальной, современной архитектуре нет никаких отдельных E и DAO. Это какой-то онанизм — сначала грузить из базы DAO, потом их превращать в E, потом обрабатывать, потом обратно превращать в DAO, и сохранять в базу.
Так никто не делает. Более того — чувак явно забыл о том, что есть ещё и DTO — ведь сервис общается и с клиентами. Поэтому полный ЖЦ этой халабуды выходит примерно таким: "получили DTO от клиента — отдали в сервис — тот преобразовал его в Е — поднял из базы пачку DAO — преобразовал их в E — как-то обработал — потом преобразовал часть E в новые DAO и сохранил в базу, а часть в DTO и отдал клиенту".
(Да, анемика по Фаулеру — говно. Впрочем, DDD по Фаулеру тоже выходит говном, из чего мы заключаем, что проблема не в анемике и не в домейн/рич, а в Фаулере.)
Забавно, что автор и сам это понимает, поэтому в тексте у него сказано "Services make use of DAO in order to implement the business logic for specific functionality". Да, совершенно верно — сервис так и работает в терминах DAO. Никакие entity ему не нужны — зачем, ведь в них же нет никакой бизнес-логики. Рассказывать про то, что "Usually, each of our entities represents separate business case, so the number of DAO classes match the number of entities. " можно только в целях напугать детишек: у-у-у, не ходите в анемик, там каждую сущность в модели надо описывать дважды, ДВАЖДЫ!
2. Идея в том, что сервис сначала подымет Entities в память при помощи DTO, а уж потом поработает над ними, описанная в статье — полный булшит, который отстал от жизни лет эдак на пятнадцать. Ну, наверное в какой-нибудь кровавой жаве так до сих пор и делают; а в нормальных современных сервисах стараются в app server лишнего не подымать. Задача сервиса — выразить бизнес-транзакцию в терминах операций над DTO; сами эти операции не выполняются над DTO, а преобразуются напрямую в SQL и уезжают в базу, где и выполняются. Если я хочу поменять статус заказа с "оплачен" на "отгружен", то я не делаю сначала select * from orders where id = @orderId в OrderDTO, и не создаю из него OrderEntity при помощи OrderEntityFactory, чтобы потом ему сделать setStatus, а потом orderDto.UpdateFrom(OrderEntity) и unitOfWork.Save(true). Нет, всё это — пережиток эпохи "а теперь дайте мне ферму из 16 PowerEdge, чтобы ваши остатки на складах подбивались хотя бы за ночь".
Делается нормальный linq-statement, который изменяет статус у того, что нужно:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Order
.Where(o => .ID == orderId)
.Set(o => o.Status, newStatus)
.Update();
}
Всё. Это превращается в SQL стейтмент, который выполняется напрямую в сервере, без подъёма килобайтов в память и длинного удержания локов.
Да, не всегда получается сделать именно так, но, поскольку мы нафиг выкинули ентити в пользу чистых "DTO", такое получается сделать гораздо чаще, чем в той убогой анемике, о которой врёт Фаулер и его фанаты.
В тех случаях, когда нам реально надо сделать что-то относительно сложное в коде сервиса, мы тащим в память не все DTO, и не каждый из них целиком — ведь на linq проекции и прочие SQL трансформации делаются лёгким движением руки, без мучительного выписывания каких-то там aggregation root или прочего. Если мне потребуется в логике проверять средний чек данного клиента — я не буду заводить для этого целый класс, будет по месту сформирован linq expression, который его достаёт сразу в виде decimal. Благодаря этому общение между сервисом и СУБД сводится к минимуму — select avg(amount) from ... всё ещё в разы быстрее, чем делать select * from, а потом усреднять в памяти.
3. Опять же читаем статью, "the application with the anemic model has more repositories than the one with the rich model". Смотрим на картинку — автор врёт даже сам себе. На его же картинке с Anemic есть ровно 0 (ноль) репозиториев. Что, в общем-то, верно отражает современную реальность. Это в говно-DDD, которое он пропагандирует, нам нужны репозитории на каждый агрегат. А в современной анемик-архитектуре "репозиториев" примерно столько, сколько есть граней у сервиса. Скажем, вся бухгалтерия — это один "репозиторий", весь складской учёт — это ещё один; управление подписками — третий; human resources — четвёртый.
И при этом эти репозитории, в отличие от DDD, не содержат никакого императивного кода. Никаких там Find или Update, специфических для каждого типа Entity. Достаточно собственно DbContext, который описывает типы. Плюс, возможно, набор extension-методов к нему и к IQueryable, которые позволяют быстро компоновать между собой куски нужного функционала. Скажем, если нам надо часто вычислять средний чек по каким-то критериям, то мы можем отдельно построить функцию decimal Average(IQueryable<decimal> source), и в коде сервиса обращаться уже к ней, с уместными в каждом конкретном случае селектами.
В итоге появляется возможность на стороне сервисов совмещать объектную и функциональную декомпозицию; а большую часть кода из DDD/рич писать вообще не нужно и даже вредно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>GoF — целиком и полностью адаптация ранее использовавшихся практик для функций высших порядков (и не только), функторов и т.п. S>>Применение паттерна "Стратегия" можно обнаружить в стандартной процедуре сортировки в "C", в WinAPI и т.п... Остальное так или иначе использовалось за десятки лет до GoF-а в функциональных языках.
S>А можно примеры?
Стратегия — посмотрите на ту же сортировку в любом ФП языке. http://www.n-a-n-o.com/lisp/cmucl-tutorials/LISP-tutorial-22.html — сортировка принимает на вход функцию, которая реализует стратегию сравнения элементов. S>Мне казалось, что GoF больше про декоратор, template method, observer, и, наконец, mvc. S>Как это было реализовано в ФП? А главное зачем все это для фп?
Декоратор — любая функция map в FP это и есть декоратор. Как мы отлаживаем самописанную функцию filter?
Описываем предикат вот так:
(defn debugPred[f]
(fn [x]
(print x)
(f x)
)
)
Всё, задекорировали. Теперь мы можем проверять, что когда вызывается:
(my-filter coll (debugPred even?))
template method — всё ровно то же самое: имеем некоторый метод, в котором есть общая часть, а есть — настраиваемая. И делаем настраиваемую зависящей от типа объекта.
Например, примерно так делается символьное дифференцирование — само дифференцирование делается шаблоном; а внутри оно делает поиск правила для переданного узла AST.
Разве что обзёрвера у нас нету, т.к. обзёрвить нечего — обычно в ООП мы обзёрвим какие-то изменения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>GoF — целиком и полностью адаптация ранее использовавшихся практик для функций высших порядков (и не только), функторов и т.п. S>>Применение паттерна "Стратегия" можно обнаружить в стандартной процедуре сортировки в "C", в WinAPI и т.п... Остальное так или иначе использовалось за десятки лет до GoF-а в функциональных языках.
S>А можно примеры? Мне казалось, что GoF больше про декоратор, template method, observer, и, наконец, mvc.
Например, тут https://fsharpforfunandprofit.com/fppatterns/
а если почитать, то тут. Но это нашел навскидку. https://dev.to/patferraggi/do-you-need-design-patterns-in-functional-programming-370c
S>Как это было реализовано в ФП? А главное зачем все это для фп?
Ну это не то, что бы кто-то сидел и повторял на ФП то, что сделали на ООП. В ФП всякие fold-ы появились со времен абстракции односвязного списка, т.е. предполагаю что на заре LISP, когда объектами еще и не пахло. Там уже умели комбинировать функции как для накопления результата при обходе графа (а накапливать могли кол-во вершин, стоимость пути и т.п. Обход один, а накопления разные, т.е. стратегия), так и что бы записывать в лог вызовы функций. Т.е. функционал декоратора, обсервера и template не требовал оглядки на ООП.
Не знаю, как было на самом деле, списывал ли кто-то решения, но одинаковые идеи часто приходят много кому в голову и в разных сферах бытия. Сетевой адаптер для измерения силы тока — тот же декоратор по сути. Источник бесперебойного питания, всевозможные умные розетки и т.п.
Как это создается? Сначала делаем некий стандартный интерфейс, куда можно подключать разные штуки. Дальше (естественно) хотим в этот же интерфейс втыкать не только стандартные штуки, а еще и штуки, выходящие за стандарт по своей функциональности. Так рождается идея адаптера/декоратора. Но вот обернуть одну функцию другой, как и другие способы комбинирования функций, в фп настолько примитивная идея, что она вряд ли заслуживает каких-то специальных терминов. Композиция — да, но это уже термин из математики.
На счет mvc — оно вряд ли могло родиться в фп.
Re[20]: DDD протаскивание других слоев через параметры методов Domain
Вероятно, в самых простых приложениях, т.е частный случай. Когда AggregateRoot по сути состоит из одной Entity и т.п.
Во всяком случае, разницу в подходах иллюстрирует хорошо, мне понравилось.
Кодом людям нужно помогать!
Re[22]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sharov, Вы писали:
AJD>>Это бредовая картинка, потому что анемика может имееть как раз такую же структуру как в DTD, с условием что вся логика в сервисах. S>Вероятно, в самых простых приложениях, т.е частный случай. Когда AggregateRoot по сути состоит из одной Entity и т.п.
Что мешает иметь сложную систему? Отсуствие логики в entity?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[23]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, AndrewJD, Вы писали:
AJD>>>Это бредовая картинка, потому что анемика может имееть как раз такую же структуру как в DTD, с условием что вся логика в сервисах. S>>Вероятно, в самых простых приложениях, т.е частный случай. Когда AggregateRoot по сути состоит из одной Entity и т.п. AJD>Что мешает иметь сложную систему? Отсуствие логики в entity?
При чем здесь сложность? Мы говорим о том, что дескать картинка при определенных условиях будет для
двух подходов аналогична, т.е. не покажет разницы:
Это бредовая картинка, потому что анемика может имееть как раз такую же структуру как в DTD, с условием что вся логика в сервисах.
Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших. Там вся соль на картинке именно в связях,
т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры.
А не только в коде.
Кодом людям нужно помогать!
Re[21]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Тут хорошая стать и отличная картинка на эту тему -- https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86?gi=40c25922c8e9 S>По-моему — очередной булшит. S>1. В нормальной, современной архитектуре нет никаких отдельных E и DAO. Это какой-то онанизм — сначала грузить из базы DAO, потом их превращать в E, потом обрабатывать, потом обратно превращать в DAO, и сохранять в базу. S>Так никто не делает. Более того — чувак явно забыл о том, что есть ещё и DTO — ведь сервис общается и с клиентами. Поэтому полный ЖЦ этой халабуды выходит примерно таким: "получили DTO от клиента — отдали в сервис — тот преобразовал его в Е — поднял из базы пачку DAO — преобразовал их в E — как-то обработал — потом преобразовал часть E в новые DAO и сохранил в базу, а часть в DTO и отдал клиенту".
DTO тут совершенно ортогонален, чтобы показать отличия он не нужен.
S>2. S>3. Опять же читаем статью, "the application with the anemic model has more repositories than the one with the rich model". Смотрим на картинку — автор врёт даже сам себе. На его же картинке с Anemic есть ровно 0 (ноль) репозиториев. Что, в общем-то, верно отражает современную реальность. Это в говно-DDD, которое он пропагандирует, нам нужны репозитории на каждый агрегат. А в современной анемик-архитектуре "репозиториев" примерно столько, сколько есть граней у сервиса. Скажем, вся бухгалтерия — это один "репозиторий", весь складской учёт — это ещё один; управление подписками — третий; human resources — четвёртый. S>И при этом эти репозитории, в отличие от DDD, не содержат никакого императивного кода. Никаких там Find или Update, специфических для каждого типа Entity. Достаточно собственно DbContext, который описывает типы. Плюс, возможно, набор extension-методов к нему и к IQueryable, которые позволяют быстро компоновать между собой куски нужного функционала. Скажем, если нам надо часто вычислять средний чек по каким-то критериям, то мы можем отдельно построить функцию decimal Average(IQueryable<decimal> source), и в коде сервиса обращаться уже к ней, с уместными в каждом конкретном случае селектами.
Вы к каким-то деталям прицепились, дескать в анемичной модели у него не ноль репозиториев в анемике. Ну с его тз
DAO и есть простенький репозиторий. Повтрюсь, суть иллюстрации в связях между компонентами соотв. уровня. В один случае дизайна
архитектуры они допускаются, и даже не неизбежны, в другом (DDD) их можно избежать. Все, больше данная картинка не на что
не претендует. Неточностей там наверняка не мало, но главное отличие картинка отлично передает. В DDD вообще практически нету
зависимостей, сложность контролируема.
Здравствуйте, samius, Вы писали:
S>>Как это было реализовано в ФП? А главное зачем все это для фп? S>Ну это не то, что бы кто-то сидел и повторял на ФП то, что сделали на ООП. В ФП всякие fold-ы появились со времен абстракции односвязного списка, т.е. предполагаю что на заре LISP, когда объектами еще и не пахло. Там уже умели комбинировать функции как для накопления результата при обходе графа (а накапливать могли кол-во вершин, стоимость пути и т.п. Обход один, а накопления разные, т.е. стратегия), так и что бы записывать в лог вызовы функций. Т.е. функционал декоратора, обсервера и template не требовал оглядки на ООП.
Да, декаратор это чуть ли не простейший паттерн, который можно сделать на ФП. Тут я ошибся.
S>Не знаю, как было на самом деле, списывал ли кто-то решения, но одинаковые идеи часто приходят много кому в голову и в разных сферах бытия. Сетевой адаптер для измерения силы тока — тот же декоратор по сути. Источник бесперебойного питания, всевозможные умные розетки и т.п.
А какая разница кто раньше? Главное где это выразительнее -- кмк, большинство паттернов в ООП будут
выразительнее и понятнее именно в ООП парадигме. Т.е. какие-то приемы в ФП можно проще выразить в ООП. И наоборот.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>Не знаю, как было на самом деле, списывал ли кто-то решения, но одинаковые идеи часто приходят много кому в голову и в разных сферах бытия. Сетевой адаптер для измерения силы тока — тот же декоратор по сути. Источник бесперебойного питания, всевозможные умные розетки и т.п.
S>А какая разница кто раньше? Главное где это выразительнее -- кмк, большинство паттернов в ООП будут S>выразительнее и понятнее именно в ООП парадигме. Т.е. какие-то приемы в ФП можно проще выразить в ООП. И наоборот.
Не соглашусь. Сколько строчек кода нужно написать, что бы выразить в ООП суть паттерна Стратегия?
На хаскеле примерно 1:
fold (+) [1,2,3,4,5]
тут мы передаем в функцию свертки списка операцию сложения элементов. И зачем нам тут ООП?
Здравствуйте, samius, Вы писали:
S>Не соглашусь. Сколько строчек кода нужно написать, что бы выразить в ООП суть паттерна Стратегия? S>На хаскеле примерно 1: S>
S>fold (+) [1,2,3,4,5]
S>
S>тут мы передаем в функцию свертки списка операцию сложения элементов. И зачем нам тут ООП?
В любом языке, где есть указатель на ф-ию вряд ли больше одной строчки кода понадобиться.
Кодом людям нужно помогать!
Re[22]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sharov, Вы писали: S>Вы к каким-то деталям прицепились, дескать в анемичной модели у него не ноль репозиториев в анемике. Ну с его тз S>DAO и есть простенький репозиторий.
Ну, то есть не выиграл, а проиграл, и не Волгу, а пять рублей. S>Повтрюсь, суть иллюстрации в связях между компонентами соотв. уровня. В один случае дизайна S>архитектуры они допускаются, и даже не неизбежны, в другом (DDD) их можно избежать. Все, больше данная картинка не на что S>не претендует. Неточностей там наверняка не мало, но главное отличие картинка отлично передает. В DDD вообще практически нету S>зависимостей, сложность контролируема. Ну это же враньё опять. Связи обоснованы бизнес-логикой. Если нам для бухгалтерии нужны остатки на складах — то связь между ними будет хоть в анемике, хоть в DDD.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Sinclair, Вы писали:
S>>Повтрюсь, суть иллюстрации в связях между компонентами соотв. уровня. В один случае дизайна S>>архитектуры они допускаются, и даже не неизбежны, в другом (DDD) их можно избежать. Все, больше данная картинка не на что S>>не претендует. Неточностей там наверняка не мало, но главное отличие картинка отлично передает. В DDD вообще практически нету S>>зависимостей, сложность контролируема. S> Ну это же враньё опять. Связи обоснованы бизнес-логикой. Если нам для бухгалтерии нужны остатки на складах — то связь между ними будет хоть в анемике, хоть в DDD.
Речь о том, где эти связи находятся\локализованы -- по всему коду, от DAO к сервисам, или только в AggregateRoot?
Здравствуйте, Sharov, Вы писали:
S>В любом языке, где есть указатель на ф-ию вряд ли больше одной строчки кода понадобиться.
Не совсем. Ещё нужна возможность конструировать функции на лету.
В приведённом примере нам повезло — функция + уже была в стандартной библиотеке, и мы ей воспользовались.
В более интересных случаях могут потребоваться одноразовые функции, которые никто в библиотеку складывать не будет. Например, функция "отрезать и выкинуть последние 4 символа строки" — чтобы избавиться от единиц измерения.
Или наоборот, "добавить ко всем строчкам указанный суффикс".
Вот такую простейшую вещь вы на языке C вспотеете записывать — потому, что в нём нету ни замыканий, ни анонимных функций. А указатели на функцию в нём, конечно же, есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ну это же враньё опять. Связи обоснованы бизнес-логикой. Если нам для бухгалтерии нужны остатки на складах — то связь между ними будет хоть в анемике, хоть в DDD.
