сервисный класс, value object и анемичная модель

[Вурдалак]

Ты можешь использовать этот термин, но он подразумевает семантически другое понятие. Ты же пытаешься свести определение к чисто технической стороне, говоря про отсутствие бизнес-логики в объекте-который-похож-на-реальную-модель. Когда говорят про анемичную модель, имеют в виду проблемы в domain model и говорят про способы их решения. С read model же таких проблем нет, поэтому называть это anemic domain model — это вносить путаницу. Терминологию вводят для упрощения взаимопонимания, а не для усложнения.

Технически — да, эти классы похожи на anemic domain model, но даже тут есть некоторые мелкие различия. Как правило, read models — это неизменяемые структуры, в то время как anemic domain models содержат сеттеры.

Ты никогда не поймёшь разницы, если будешь и то, и другое называть одинаково.

 

[Sufir]

grigori, разве не подразумевается модель предметной области? Т.е. модель предметной области (Domain Model) может быть анемичной (Anemic Domain Model) или не быть (Rich Domain Model). Имеет ли вообще смысл данный термин использовать в отрыве от именно модели предметной области? Та же упомянутая Вурдалаком read model не "не используется для абстрагирования при передаче данных между слоями", но какой она может быть, как не "анемичной", если там по большому счету ничего кроме данных не требуется и главное она не обязана в полной мере отражать предметную область и реализовывать бизнес правила - её ответственность UI? Я на данный момент это так понимаю.

 

[grigori]

@Вурдалак, вот так намного понятнее, спасибо.
когда это "микросервисными архитектурами, CQRS" - все понятно, результат запроса в массиве идет прямо на вывод,
а вот в "аналитике-статистике и подобных вещах" данные очень даже обрабатываются перед выводом, я именно эти слова процитировал в вопросе

 

[Вурдалак]

а вот в "аналитике-статистике и подобных вещах" данные очень даже обрабатываются перед выводом, я именно эти слова процитировал в вопросе

Логика обработки, в принципе, вполне может быть бизнес-логикой, просто она скорее всего будет в другом контексте. Т.е. у тебя есть Пользователи и есть Заказы, которые они оформляют. Здесь своя бизнес-логика, которая вполне успешно живёт без знания о каких-то отчётах для менеджеров. А при формировании отчёта мы можем обращаться к domain-сервисам из другого контекста, который принимает на вход определенные данные и возвращает насчитанные проценты и прочее. Но до тех пор, пока эта логика будет достаточно примитивной, мы можем не выделять этот в отдельный контекст, херачить её прямо в инфраструктуре или presentation и считать слишком простой для того же DDD.

 

[grigori]

@Sufir, все было понятно вплоть до слова UI.

 

[fixxxer]

@Вурдалак, вот так намного понятнее, спасибо.
когда это "микросервисными архитектурами, CQRS" - все понятно, результат запроса в массиве идет прямо на вывод,
а вот в "аналитике-статистике и подобных вещах" данные очень даже обрабатываются перед выводом, я именно эти слова процитировал в вопросе

Тут есть три варианта.

1) Обработка сырых данных из базы (допустим, что-то неудобно делать sql-запросом), это прям сразу до создания этих самых read models / VO / call it what you want
2) Трансформация/агрегация/объединение с другими данными под конкретную presentation логику - такое делается вполне себе либо в presentation layer, либо в каком-нибудь report builder
3) Какая-то простейшая вычислительная логика, уместная в этой read model, типа getDistance() => return this.$speed * this.$time.

 

[grigori]

резюмирую: анемичные модели для примитивной, простейшей вычислительной логики, и медиатор для объединения данных из нескольких источников

 

[Вурдалак]

https://developers.facebook.com/docs/graph-api/reference/v2.5/album/ — возвращаемое значение тут, по сути, сериализованная read model Album. И эта модель нужна для передачи данных об альбоме. Довольно странно говорить тут о какой-то логике и анемичности. Тут логики не должно быть по определению.

 

[Sufir]

@Sufir, все было понятно вплоть до слова UI.

Я имел ввиду пользовательский интерфейс, данные для которого содержат объекты read model-и.

 

[grigori]

@Sufir, @Вурдалак, вы опять говорите про CRUD/CQRS/REST, этот случай я не рассматриваю.

Вопрос в аналитике, в которой обработка нужна.

когда это "микросервисными архитектурами, CQRS" - все понятно, результат запроса в массиве идет прямо на вывод,
а вот в "аналитике-статистике и подобных вещах" данные очень даже обрабатываются перед выводом

Например, нужен список покупателей, которые в прошлом сделали заказов на общую сумму более 50 тысяч рублей, но ничего покупали за последний год - им надо разослать купоны на скидку.
Если биллинг в отдельной базе - одной read model не обойтись. И ...

Тут есть три варианта.

давайте дальше по теме

 

[HORO]

Ну надо же, впервые услышал что SL это плохо...кто это пишет?

 

[fixxxer]

Хорошо или плохо - это не очень конструктивно, лучше говорить о недостатках.
Ну вот классика - http://www.martinfowler.com/articles/injection.html

 

[HORO]

Ну да, каждому инструменту свое применение (а вот в топике откуда перенесли мое сообщение SL сразу назвали плохим) и по ссылке SL автор не обзывает антипаттерном.