не соглашусь, скаляр - не обязательно настройка

Если сервису через DIC в конструктор передают не только сервисы и настройки, то это highly likely запашок.

@b101010 postfix. Две разные имплементации mta

http://shearer.org/MTA_Comparison

Если сервису через DIC в конструктор передают не только сервисы и настройки, то это highly likely запашок.

Можешь привести пример передачи code smell структур, функции , entity или еще что ?

Если сервису через DIC в конструктор передают не только сервисы и настройки, то это highly likely запашок.

да нет никакой разницы со стороны сервисов, DI да и только... что скаляры, что объекты, что функции - все можно инжектить

интересно другое: как это разрешается извне

Можешь привести пример передачи code smell структур, функции , entity или еще что ?

Так всё в кучу: $service = new ActivateService($repo, $user, $date); $service->activate(); Сервис мутабельный, в контейнер без фабрики не запихнёшь. А так с разделением: $service = new ActivateService($repo); $service->activate($user, $date); Теперь иммутабельный и переиспользуемый.

не, уже не сегодня я вот смотрю на if err != nil и чет думаю про монады Maybe

А почему бы и нет?

Ааа.. Maybe это был не "мб"

Ааа.. Maybe это был не "мб"

:) да то я так, умных людей в чате начитался и думаю о том, чего не понимаю

Блин, выглядит прикольно

:) да то я так, умных людей в чате начитался и думаю о том, чего не понимаю

Хм, чатик по го?

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

Так всё в кучу: $service = new ActivateService($repo, $user, $date); $service->activate(); Сервис мутабельный, в контейнер без фабрики не запихнёшь. А так с разделением: $service = new ActivateService($repo); $service->activate($user, $date); Теперь иммутабельный и переиспользуемый.

ну есть еще всякие регистри которые как бы хранят стэйт

и от них не избавиться

ну есть еще всякие регистри которые как бы хранят стэйт

Ну рантаймовский statefull сервис - это как global variable на свой страх и риск. Но и их местами можно из $registry->set(...) переделать в иммутабельные $registry->with(...) и передавать в методы явно.

Ну рантаймовский statefull сервис - это как global variable на свой страх и риск. Но и их местами можно из $registry->set(...) переделать в иммутабельные $registry->with(...) и передавать в методы явно.

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

У меня доменная модель юзера в DDD уже на 2 к строк, это нормально?)

нет

закинь на гист, заценим

У меня доменная модель юзера в DDD уже на 2 к строк, это нормально?)

Если ты делаешь толстые модели, то да. Хорошо ли делать толстые модели уже другой вопрос.

Если ты делаешь толстые модели, то да. Хорошо ли делать толстые модели уже другой вопрос.

нет, даже с рич моделями 2к - это не хорошо

ты хочешь поговорить о том, почему рич модели - это плохо?)

ты хочешь поговорить о том, почему рич модели - это плохо?)

Кстати оказывается термина рич модел нет

Есть обычная нормальная модель, а есть уебанская анемичная

А типо рич просто как противопоставление появилось в разговорной речи

У меня доменная модель юзера в DDD уже на 2 к строк, это нормально?)

есть высокая доля вероятности что нет. Как понять что не так и почему она жирная: - берешь все свойства сущности (кроме айдишки), и смотришь как они юзаются. Тебя тут интересует только запись. - какие-то поля возможно стоит вынести в VO а какие-то в отдельную сущность (поскольку на запись только в контексте группы полей работаешь а не в контексте всей сущности юзера). - очень часто большое количество полей (и как следствие логики по работе с этими полями) оказываются в одном классе просто так, потому что и то и другое про юзера. Пример - пароль и весь стэйт связанный с авторизацией. Тебе он нужен только в момент авторизации, далее ты просто его таскаешь как мертвый груз. Причем в момент авторизации тебе нужен только кусок стэйта. Вывод - можно разбить это дело на 2 сущности независимые (у которых может быть связь через айдишку)

Есть обычная нормальная модель, а есть уебанская анемичная

А "обычная" это какая?

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

А "обычная" это какая?

ну это как модель здорового человека

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

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

тип все, что уходит во вьюшку - в одну сущность?

тип все, что уходит во вьюшку - в одну сущность?

очень упрощенно - да. Оно там конечно не в одну сущность. Еще могут быть связи в одну сущность просто потому что в одной вьюшке юзаются.

а причем тут ООП?

ну это как модель здорового человека

Не, "модель здорового человека" это на ADT, но к ООП это не имеет никакго отношения

Не, "модель здорового человека" это на ADT, но к ООП это не имеет никакго отношения

ADT это напомни что? алгебраические типы данных?

а причем тут ООП?

Возможно и нет, но мне так и не объяснили что такое "нормальная модель". Или почему "низкая связанность, высокое зацепление, разделение" не может быть в анемичных моделях.

ADT это напомни что? алгебраические типы данных?

ага

Возможно и нет, но мне так и не объяснили что такое "нормальная модель". Или почему "низкая связанность, высокое зацепление, разделение" не может быть в анемичных моделях.

тут "нормальная" в контексте декомпозиции, а классы, тайпклассы ли или прочие ADT тут роли не играет. Да с ADT можно более выразительно многие вещи описывать с меньшим количеством кода, но в целом мы можем представить что пишем на ruby и у нас нет ни ограничений ни типов)

"модель" ты можешь трактовать как модуль. Там у тебя будут объявлены типы и функции которые работают с этими типами. И все нюансы которые приводят к "моделям" на килостроки кода это в основном криво проведенные границы между модулями

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

всем спасибо, вынесу некоторые методы, и параметры в доп сущности и сгрупирую в VO.

@fes0r ваши ответы иногда надо записываю себе в save msgs ;)

@fes0r ваши ответы иногда надо записываю себе в save msgs ;)

а иногда не стоит)

поетому иногда)

у мну логика наверн тяжелая в етом все дел, апдейт емейл выходит 2 метода, 1-й записывает ивент изменения стейта vo userEmail, и второй метод применяет ивент к стету модели, что то в духе Flux, я думаю, с фронта

любое изменение стейта, через ивент.

16 полей + 14 связей :3

у мну логика наверн тяжелая в етом все дел, апдейт емейл выходит 2 метода, 1-й записывает ивент изменения стейта vo userEmail, и второй метод применяет ивент к стету модели, что то в духе Flux, я думаю, с фронта

что-то в духе event sourcing

Угу)

Flux он же на ивентах и про ивенты тоже

и там тоже стейт есть

ну вот у меня есть такой на 600 строк

https://www.fullstackreact.com/p/intro-to-flux-and-redux/

https://www.fullstackreact.com/p/intro-to-flux-and-redux/

да знаем мы, но не надо называть это flux/redux. Там как никак упрощено сильно

Упрощено?)

а че там сложного?

непривычно - возможно, но не сложно

Для изменения стейта, диспатч ивента, которой тригерет екшен, который тригерет мутатор, который изменяет стейт

там все сложности не технические а организационные. Типа "а че будет если я проипался и у меня

ERROR: S client not available

этот ивент это на самом деле 2 ивента"

Это не Ларавел в общем ?

Я кстати хз как бы делал такое в ларавел

Для изменения стейта, диспатч ивента, которой тригерет екшен, который тригерет мутатор, который изменяет стейт

не так.... 1. проверяем прекондишен 2. запоминаем ивент внутри сущности 3. триегрим обработчик события внутри сущности для выстраивания стэйта write модели

Я кстати хз как бы делал такое в ларавел

http://getprooph.org/

читаю

@fes0r мне кажеться, тут все то чт оя делаю сейчас с нуля

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

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

Что бы понять других разработчиков нужно думать как они

Нужно быть ими

ничего, года через 3-4 пройдет

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

потому что ответ тебя расстроит

угу.... сделали так либо потому, что им подходило, либо потому, что не придумали, как лучше =\

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

Всем доброго дня! Следующий вопрос: есть yii2, есть SqlDataProvider. Имеет ли право Repository работать с такими провайдерами внутри себя или это не clean способ?

тут наверное у всех фильтр на сообщения по слову yii

тут не чатик по yii, это точно

Хорошо. Но вопрос был не по Yii2) Вопрос был по архитектуре. Конкретизировал для лучшего понимания)

Хорошо. Но вопрос был не по Yii2) Вопрос был по архитектуре. Конкретизировал для лучшего понимания)

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

мне кажется в репозиторию можно любую хуйню инджектить, будь то просто обертка над sql или маппер. Лишь бы наружу торчали номральные методы с человеческими именами

мне кажется в репозиторию можно любую хуйню инджектить, будь то просто обертка над sql или маппер. Лишь бы наружу торчали номральные методы с человеческими именами

Спасибо

мне кажется в репозиторию можно любую хуйню инджектить, будь то просто обертка над sql или маппер. Лишь бы наружу торчали номральные методы с человеческими именами

более того, в yii любую херню можно инжектить в любую другую херню, и будет ок, это ж yii

array oriented programming

@fes0r привет, ходят слухи по интернетам, что ты пробовал php-pm, расскажи, как оно, стоит ли потратить время, чтобы пощупать? Какие очевидные подводные попадаются? Как в целом?

@fes0r привет, ходят слухи по интернетам, что ты пробовал php-pm, расскажи, как оно, стоит ли потратить время, чтобы пощупать? Какие очевидные подводные попадаются? Как в целом?

ну с учетом того что под php-pm есть готовый Dockerfile то подводные камни в целом те же что и для других вариантов всяких воркеров - кто-то из твоих сервисов может активно гадить в память, не быть преспособленным к тому что в пределах жизн ипроцесса может быть два+ запроса и т.д.