интересует еще мнение, может быть не ваше а с которым сталкивались

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

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

вся логика в одном сервисе?

это да, бывает сложно сориентироваться но это вопросы к тем, кто реализовал

ну не обязательно в одном, как получится)

а, ну я понял, когда одна какая-то "логика" размазана по сущностям потому что это "процесс" а не логика

ну не обязательно в одном, как получится)

типа как у нас было завершение заказа?)

сервис в сущность, это фу

не фу, иногда надо

и иногда можно сделать красиво

соц опрос для тех кто считает что бизнес логике в сущностях не место: почему вы так считаете?

а вообще, тут больше кто как думает, если ты оперируешь данными, точнее структурами, то логика их обработки у тебя будет где-то отдельно от них

ты не рассматриваешь свою бизнес логику в виде объектов

вот и все)

и иногда можно сделать красиво

как?

а вообще, тут больше кто как думает, если ты оперируешь данными, точнее структурами, то логика их обработки у тебя будет где-то отдельно от них

ммм я думаю тут вопрос не в том что ты данными оперируешь, а в том как ты группируешь эти данные. Чаще всего ты делаешь это не учитывая то что ты с ними будешь делать

как?

надо придумать юзкейс)

ну в идеале твое приложение это модель бизнеса

ну в идеале твое приложение это модель бизнеса

не только модель бизнеса, она должна содержать эту модель

но это мелочи

модель бизнеса... твое приложение это только частица бизнеса0

а в реале, это приложение для манипуляции с данными

как?

вообще - через ивенты жизненного цикла сущностей можно пробрасывать разные штуки, например сделать не сервис а коллекцию какую-то которая предоставляет к внешним данным доступ

не только модель бизнеса, она должна содержать эту модель

ну мне впадлу писать больше прост)

ну мне впадлу писать больше прост)

я тебя понял)

надо придумать юзкейс)

начал писать юзкейс, вспомнил, что он в принципе ложится в сущности, но чуть запарно (расчет доступности объектов недвижимости по заданной дате)

начал писать юзкейс, вспомнил, что он в принципе ложится в сущности, но чуть запарно (расчет доступности объектов недвижимости по заданной дате)

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

я тебя понял)

так что, как по мне, это основная причина почему люди делают так

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

в твоем варианте да но я стараюсь обходиться без этих ивентов я их пока не до конца освоил + завязка лишняя на доктрину

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

да

вот я когда-то докладик смотрел

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

вот последнее - и есть корень многих проблем. Как правило с анемичными моделями у тебя будет больше зависимостей

какой-то джавист рассказывал, про оверинжинириг

какой-то джавист рассказывал, про оверинжинириг

у меня под рукой только видос с каким-то дотнетчиком

вот последнее - и есть корень многих проблем. Как правило с анемичными моделями у тебя будет больше зависимостей

а бывает и обратное, что метод нужен только в одном месте, и то в каком-то сервисе

ну суть сложно и архитектура должна идти от бизнеса

и если этот метод не добавит читаемости коду, то нахер

если нам нужно сделать приложение для конфы, про которое потом забудут

нах нам архитектура)

а бывает и обратное, что метод нужен только в одном месте, и то в каком-то сервисе

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

нах нам архитектура)

прикол в том что я нахожу эти подходы одинаковыми по сложности

во всяком случае с точки зрения запилить по быстрому

чистую модель ты в любом случае не сделаешь в силу несовершеннства бытия

ну тут я больше придерживаюсь такого правила как со стаческими методами. если метод не привязан к определенному инстансу - то его стоит сделать статикой, чтобы читая код было понятно что скоуп довольно узкий так и с сущностями, если код в сущности, то 100% этот код не юзает внешние зависимости

ну тут я больше придерживаюсь такого правила как со стаческими методами. если метод не привязан к определенному инстансу - то его стоит сделать статикой, чтобы читая код было понятно что скоуп довольно узкий так и с сущностями, если код в сущности, то 100% этот код не юзает внешние зависимости

если сущности нужен релейшен свой - это внешняя зависимость?

релейшены это все в рамках одного графа, там окей

ну я обычно к сервисам прибегаю тогда, когда что-то что нужно не относится к конкретной сущности

например - история заказов

есть репосы)

есть репосы)

а есть to many релейшены

а есть to many релейшены

а потом воюем с миллионами запросов к базе

вместо одного оптимального

с нужными джоинами и тд

вместо одного оптимального

CQRS =)

вот да - надо специфику операции учитывать)

например - история заказов

так себе пример, это репозиторий или еще не репозиторий

CQRS =)

ты делаешь покупку, тебе нужно на основе истории заказов юзера посчитать его скидку и финальную цену. это относится к "C"?

ты делаешь покупку, тебе нужно на основе истории заказов юзера посчитать его скидку и финальную цену. это относится к "C"?

да

но ты можешь в С юзать read model

стейт приложения меняется?

может и меняться, например когда ты оформляешь заказ

если нет, то это не совсем команд

если нет, то это не совсем команд

ну мы это понимаем

суть в том что я не вижу особо проблем

с 10 лишними простыми запросами в базу

но ты можешь в С юзать read model

и к чему тут CQRS тогда?) от того что я сделаю запрос к базе не привязанный к сущностям, это не значит что я пошел по дороге CQRS

меня больше заботит не то сколько у меня запросов к базе (пока оно не влечет за собой респонс тайм больше 100-200 милисекнуд) а то насколько логика между собой разделена что бы мне было удобно вносить изменения

с 10 лишними простыми запросами в базу

у нас к примеру на странице просмотра продукта выполняется около сотни запросов(если считать что мы без кеша), 10 лишних запросов легко выливаются в тысячу. поэтому доктрину надо контролировать..

ммм.... кэш

ERROR: S client not available

короч Серег, мы коней в вакууме обсуждаем

это дурацкая идея

меня больше заботит не то сколько у меня запросов к базе (пока оно не влечет за собой респонс тайм больше 100-200 милисекнуд) а то насколько логика между собой разделена что бы мне было удобно вносить изменения

ну тут дело такое, иногда 10 запросов лучше чем 1, а бывает наоборот. все по ситуации зависит и от запросов

то что у тебя там специфика какая-то - это операция на чтение, это легко скорее всего закэшить как-то

кешить можно то на что есть хиты)

ну тут дело такое, иногда 10 запросов лучше чем 1, а бывает наоборот. все по ситуации зависит и от запросов

конечно по ситуации, кто-то иначе считает?

кешить можно то на что есть хиты)

у большинства вся база в оперативку влазит

тут бы индексы влазили

а ты за базу

ну такое

ты уже юзаешь шардинг?)

в кластере монги уже вроде два десятка нод

эх...

когда уже у меня будет проект где база в оперативку не помещается...

и на эластике тоже уже не помню сколько там, но меньше явно чем в монге

и к чему тут CQRS тогда?) от того что я сделаю запрос к базе не привязанный к сущностям, это не значит что я пошел по дороге CQRS

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

что бы база хотя бы терабайт(

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

это тоже бизнес логика - просто контекст другой

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

блин на каких проектах вы работаете что у вас чтение такое простое?

типа выбрали и показали все как есть

ну как простое)

что ты рассказывал, посчитать, обсчитать тоже есть)

типа выбрали и показали все как есть

не так, просто данных меньше и 100 запросов к базе на 4-х репликах никого особо не напрягают)

не так, просто данных меньше и 100 запросов к базе на 4-х репликах никого особо не напрягают)

100 запросов с одного клиента...

не так, просто данных меньше и 100 запросов к базе на 4-х репликах никого особо не напрягают)

тоже верно

и это хорошо пока клиентов мало) так еще помимо клиентов есть целая инфраструктура для процессинга данных, которая тоже хочет пользовать базы

и это хорошо пока клиентов мало) так еще помимо клиентов есть целая инфраструктура для процессинга данных, которая тоже хочет пользовать базы

100rps система выдает - нам норм. Надо будет больше - будем думать

я не к тому что давайте меряться тому у кого толще база и у кого больше rps

а я к тому что бы решать проблемы в порядке их приоритета

я к тому что чтение не всегда тривиальное, и кеш не всегда панацея