@oop_ru

Страница 428 из 785
Артур Евгеньевич
14.12.2017
22:55:12
я понимаю, но выйдет сервис с ~30-40 методов
Не вижу тут столько методов. Тут только покупка

Sergey
14.12.2017
22:55:50
Не вижу тут столько методов. Тут только покупка
покупка подразумевает возможность просмотреть товары, товары кто-то должен добавлять, добавление товаров подразумевает какую-то премодерацию, версионизацию, аудит.

Артур Евгеньевич
14.12.2017
22:55:55
И возможно разные ее варианты- сразу, в кредит, в счет бонусо(Но это все полиморфизмм разрешитьс

Google
Sergey
14.12.2017
22:56:38
а еще есть реферальная система (бонусы рефералам), а еще есть скидки и акции на конкретные товары, а еще есть разные варианты оплаты, а еще оплата может быть... чуть сложнее чем один вызов сервиса

куда это все пихать?

Это разные сервисы будут
ну так и сущности разные)

Артур Евгеньевич
14.12.2017
22:57:11
ТовароПрочмоторщик, Склад, модерэйт

Sergey
14.12.2017
22:57:35
ТовароПрочмоторщик, Склад, модерэйт
песочница для мерчандайзера, поиск

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

в наших филосовских изысканиях

предположим что завтра Intel опубликует новости что они достигли прорыва с 3dxpoint и теперь у нас может быть до жопы энергонезависимой RAM не уступающей по производительности обычной

таким образом мы исключаем из уравнение хранение данных

нам не нужна будет база данных короч

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

Артур Евгеньевич
14.12.2017
23:00:39
Как дело было изначально- на пивном афтерпати после симфони митап несколько чуваков у которых опыта больше чем у меня лет на 10 начали доказывать что сервисы понятнее м проще чем богатые сущности, которые вообще ток для книжек с хелловорлом годятся, я начал спорить но не вывез(к сожалению уже не вспомню большую часть аргументов)...и вот щас решил все еще раз переосмыслить

Google
Артур Евгеньевич
14.12.2017
23:01:54
дело полезное, но все же ответь на вопрос - как меняется сложность если мы базу данных выкидываем?
Ну в случае с ричДомэйн никак не меняется просто выкидываем слой персист

Sergey
14.12.2017
23:02:23
Ну в случае с ричДомэйн никак не меняется просто выкидываем слой персист
я про то, что теперь у тебя есть данные и поведение. Количество данных и поведения в целом одинаково, так?

вопрос только в том как ты это дело располагаешь, внутри или снаружи

и еще очень важный вопрос - зависимости

давай вместо rich domain будем использовать термин whole value

он как-то более точно передает смысл

Артур Евгеньевич
14.12.2017
23:05:40
я про то, что теперь у тебя есть данные и поведение. Количество данных и поведения в целом одинаково, так?
Не совсем понял но придумал кейс. Допустим есть операция - регистрация по рефералке, с автоматическим подарком товара дня, и вип статусом на 2 дня, а с очмщениием всей задолженности

Sergey
14.12.2017
23:06:05
допустим

Артур Евгеньевич
14.12.2017
23:06:28
В анемичной я бы создал сервис vipRefRegistration

Наинджектил бы в него сервисов - регистрации,покупки,випа и депозита

И дергал бы у них методы с нужным параметром

А в whole value

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

kana
14.12.2017
23:08:36
как я понял из диалога - анемичная - это когда логика в сервисах, а модель - тупо чтобы представить базу данных в коде

kana
14.12.2017
23:09:23
(прямо как принято делать в фп-языках без ооп, лол)

Sergey
14.12.2017
23:09:38
Наинджектил бы в него сервисов - регистрации,покупки,випа и депозита
теперь меняем требования: 1. автоматический подарок только если ты привел каждого 5-ого реферала 2. отчищение всей задолжности только если ты привел 10 рефералов.

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

Google
Sergey
14.12.2017
23:11:47
не забывай о том что перечисленная тобой логика находится в разных контекстах

Артур Евгеньевич
14.12.2017
23:14:40
теперь меняем требования: 1. автоматический подарок только если ты привел каждого 5-ого реферала 2. отчищение всей задолжности только если ты привел 10 рефералов.
Можно делать проверку после добавления реферала и дергать сервис випок...или сразу дергать сервис випок в котором инкапчулироуать проверки

Но вот проверка на то что рефералов меньше 5

Sergey
14.12.2017
23:15:12
Можно делать проверку после добавления реферала и дергать сервис випок...или сразу дергать сервис випок в котором инкапчулироуать проверки
и будет у тебя куча сервисов, с кучей зависимостей, которые связаны друг с другом и часто пересекают границы контекстов

Артур Евгеньевич
14.12.2017
23:15:24
К какой сущности можно присоьачить

Sergey
14.12.2017
23:15:35
к сущности Referral)

у которой будет информация кого кто пригласил

и сколько

Артур Евгеньевич
14.12.2017
23:16:12
А так ясно что операция выдачи випок, и в нее инклюдить разные проверки можно даже объекты.

Sergey
14.12.2017
23:16:29
я если что не говорю что это "единственно верный способ" но в конечном счете для меня я другого варианта делать удобно не нашел

Артур Евгеньевич
14.12.2017
23:17:20
и сколько
Эт уже агрегат какойто. В моем понимании реферал содержит только айди приглаисвшего

А подсчет это или репозиторий или мапер или сервис отдельный

Sergey
14.12.2017
23:17:54
Эт уже агрегат какойто. В моем понимании реферал содержит только айди приглаисвшего
реферал - элемент дерева. Он будет содержать то что нужно

Артур Евгеньевич
14.12.2017
23:18:42
Ну тогда репозиторий, который может получать любые рефералы

Которые есть в программе

Sergey
14.12.2017
23:19:19
забудь про репозитории

Артур Евгеньевич
14.12.2017
23:19:20
ты когда-нибудь юзал доменные ивенты?
Нет, но в текущем проекте у нас используются

забудь про репозитории
Я имел ввиду коллекция

Google
Sergey
14.12.2017
23:19:41
Нет, но в текущем проекте у нас используются
на всякий случай, доменный ивент - это некий факт произошедший с сущностью.

Я имел ввиду коллекция
да, коллекция норм.

так вот...

при регистрации я кину ивент что пользователь зарегистрирован. а так же сделаю нового реферала. Реферал кинет свой ивент о том что кто-то его пригласил (или нет, если это не так)

и будет простой листенер который будет слушать явный тригер "кто-то кого-то пригласил"

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

для каждого кейса можно свой листенер сделать (если в разных контекстах)

и т.д.

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

Артур Евгеньевич
14.12.2017
23:24:33
Да с событиями выглядит логично. А без них получается никак? И как события группировать? Сущность знает о своих событиях или не?

Sergey
14.12.2017
23:25:13
без событий я пока не умею... но в теории через медиаторы выходит не хуже

> И как события группировать? а зачем их группировать?

ты еще учти что у меня основной загон - снижение связанности и увеличение изоляции системы

возможно даже слишком...

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

Артур Евгеньевич
14.12.2017
23:31:27
Лан спасибо за диалог,я спать. Завтра еще перечитаю на свежую голову. Но раз без событий нельзя то по сути мы пришли к сравнению SOA и Es

Sergey
14.12.2017
23:32:15
как мы к нему пришли?)

Mykola
14.12.2017
23:32:25
без событий можно, на flow

Sergey
14.12.2017
23:32:31
SOA если что не про "сервисы и анемичную модель" - это по сути микросервисы

Google
Mykola
14.12.2017
23:32:34
приветы

Sergey
14.12.2017
23:32:38
без событий можно, на flow
расскажешь подробнее?)

kana
14.12.2017
23:33:33
Бугаенко вроде как высказывается против DDD, но при этом в том докладе, что скидывали вчера, все тезисы соотстветсвуют DDD (типа не выносить логику объекта из объекта)

Mykola
14.12.2017
23:33:36
на верхнем уровне ты определяешь граф потоков

Mykola
14.12.2017
23:34:17
о, я еще не говорил за ддд

ддд - очень плохо, но не из-за дизайна, а из-за дурацких терминов

они все портят в ддд

не семантично

вот кто можешь обьяснить почему велью-обжект так называется?

почему не просто велью и не просто обжект? :)

Sergey
14.12.2017
23:36:27
вот кто можешь обьяснить почему велью-обжект так называется?
потому что этот объект представляет собой некое значение. Это нужно что бы отличать от просто объекта, так как сущность - это тоже объект)

но я тебя понял - если мы будем просто делать ООП мы так или иначе придем к тому же но без оверхэда по терминогии. Агрегат сущностей - граф объектов, корень агрегата - вершина графа объектов, ограниченный контекст - модуль

а еще все можно модулями звать с точки зрения функциональности)

kana
14.12.2017
23:38:16
ну вот есть в DDD термин Closure of Operations

это так называемая магма из алгебры

ну или группоид

Sergey
14.12.2017
23:39:01
а вот для таких терминов я туповат(

kana
14.12.2017
23:40:03
это просто множество и бинарная операция объединения двух элементов множества в один элемент этого же множества

Mykola
14.12.2017
23:44:07
вот и говорили бы, групоид)

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

это в математике множетва предсказуемы, а в программировании ты можешь объеденить два элемента и получить какую-то фигню)

Страница 428 из 785