Мне уже @fes0r советовал Эванса

эванс вроде не отвечает на вопрос "кому и когда нужно ddd"

он типа намекает (по поводу управления сложностью) но не очень конкретно

он больше по теории, Вернон больше по практике

почитаю, спасибо

а кто нибудь эванса цитал целиком

я чето начала пздц как нудно

нашел конспект какой то DDD quickly но там на инглише а у меня он нот пёрфект

лучше тянуть инглиш, чем искать тех, что читал эванса целиком)

а за конспект спасибко, закину его в библиотеку чатика

аааакозлы на их сайте три кнопки - pdf, epub и mobi для того, чтобы скачать епаб (которого нигде вроде не вижу помимо этого сайта) - нужно зарегаться зарегался - а там, мать их, ссылка на пдф...

есть на русском от Вернона - Предметно-ориентированное проектирование.Самое основное.

есть на русском от Вернона - Предметно-ориентированное проектирование.Самое основное.

да вернон и так на русском есть...только не в электронном виде

возникла идея для ТГ бота для чатов чтобы по "зову" автоматом постил на github pages ссылку с описанием

Кароч просто в реакте хотят зафорсить DDD

Поэтому я и спросил)

хотя может эти твиты с реактом и не связаны

?

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

https://medium.com/theuidev/what-exactly-is-ui-development-7d6e8b27320d

Хз почему-то везде про DDD пишут

именно к UI

нашел конспект какой то DDD quickly но там на инглише а у меня он нот пёрфект

http://carfield.com.hk/document/software%2Bdesign/dddquickly.pdf оно ?

да

А мне начали лечить че-то про классы, агрегаты, методы тут

да, уже на oopru.github.io добавлено

ну тут бекендеров больше все же, что ж поделать

да, уже на oopru.github.io добавлено

кстати я бы лучше добавляя русские флажки к русским материалам а не писал (EN) на инглише + для видео иконку ютуба, а не делил на смотреть читать. А разделил бы уже по категориям GoF DDD и т.д так что если у кого будет время то вот

кстати я бы лучше добавляя русские флажки к русским материалам а не писал (EN) на инглише + для видео иконку ютуба, а не делил на смотреть читать. А разделил бы уже по категориям GoF DDD и т.д так что если у кого будет время то вот

just do it :)

я все это редактирую прямо в интерфейсе

я пок аконтрибьютил тока дизайн))

давайте еще около-DDD вопрос есть у меня сущность клиента и несколько дочерних от него сущностей (неважно сейчас, на самом деле)

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

а зачем тут вообще сервис? ну и если это agregate root то логичен каскад при сохранении

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

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

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

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

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

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

ну не, так не бывает)

такой агрегации?

если дочерние - это VO, тогда да, не мой кейс но у меня иерархия сущностей именно такая - все под клиентом

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

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

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

тут нужно мне серьезно вникнуть в эти нюансы

в таком варианте не вижу разногласий

клиент - агрегат, дочерние сущности клиента - тоже агрегаты

Ага, могут быть, но в других контекстах.

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

Если в одном то стоит задуматься о границах контекстов. Возможно, только возможно, что они слишком велики.

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

Что скажите про такой подход к товарам для инет магазина? Каждый товар как физический объект индивидуально заносится в БД. Смартфон - 64гб - цвет красный - цена. Одна запись в бд без модификаций. Далее много таких товаров однотипных оъеденяем в группу - Смартфон Х. При переходе показываем первый по умолчанию товар и из выпадающего списка - похожие. Из плюсов легкий импорт/экспорт в ту же 1с и другие бд и нет ебли с модификациями

А у тех же модификаций зависимость друг от друга. И в каждой категории свои модификации с разными типами могут быть

А в том подходе не нужно создавать доп. Таблицы

Пример готовый fasttech.com

Или группа может быть виртуальной. Просто показываем выпадающий список с похожими товарами который руками заранее определили при добавлении товаров

А в том подходе не нужно создавать доп. Таблицы

А без этого подхода ты часто создаёшь дополнительные таблицы?

Там дискусс в yii2 чате если чего

Там дискусс в yii2 чате если чего

а можешь на него ссылку кинуть?

@yii2ru

лол, че поменяли название чата?

так давно ведь

@fes0r

лол, че поменяли название чата?

Потому что мы тут стали больше про дизайн, чем про ООП.

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

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

ERROR: S client not available

ну сделай шаблонный метод у суперкласса

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

в отдельные функции? в трейты?

в отдельные функции? в трейты?

но оопшненько было бы вынести, например, в отдельный слой

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

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

вообще есть неплохой шаблон для работы с подобным — презентеры

А я на свой вопрос не оопшныц все никак не начну делать. а че вы скажите?)

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

очень правильный вопрос

А я на свой вопрос не оопшныц все никак не начну делать. а че вы скажите?)

....я ничего не понял из этого сообщения

Ничего не изменилось

А я на свой вопрос не оопшныц все никак не начну делать. а че вы скажите?)

SOA, core делится на несколько сервисов по бизнес задачам уже начал на вход ставить отдельный умный сервисы, который любые внешние запросы - преобразует в сервисные - выступает в качестве превратника для API-call. а теперь некст степ: - хочу на него же повесить авторизацию oAuth - внутрь пропускает только те запросы которые прошли предварительную фильтрацию, вешает флаги типа авторизация, user_id - сервис stateless, не видит бд и я не хочу чтобы он её видел

собственно вопрос на поверхности

собственно вопрос на поверхности

типа нужно ли тебе soa?)

не вижу вопроса

нет кнчн

КАК

что как?

"преобразует в сервисные" - че?

возьми jwt, будет тебе stateless в некс левел пускают только подписанные через Bearer

ты какой-то api gateway мутишь?

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

ты какой-то api gateway мутишь?

да. + превратник

на самом деле сам gateway на service-bus

но суть та же

вопрос как сделать не тольк о чтобы работало, а чтоб по красоте )

там сейчас лара но эт оскорее чтобы не огранмичивать себя. можно на люмен свичнутся

и только для API

Артур, без четко выраженных бизнес требований, ответ на твой вопрос как сделать красиво/по умному — 42.

Артур, без четко выраженных бизнес требований, ответ на твой вопрос как сделать красиво/по умному — 42.

ну да ну да

очевидно же всё

никакого космоса

всё нарачито банально