Так бывает, когда читаешь только оглавление...

аааа, ступил чего-то

Ddd в опенсорсе по определению быть не может

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

Ладно, давайте предметнее. Вот у меня есть сущности: новости, тизеры. Есть к этим новостям всякие метрики. Стоит ли физически выделять в отдельную папку метрики или же закапывать там же где и сущности, т.е. в тех же папках???

в какой-то репе видел примеры реализации расписанные типа по коммитам "пошагово"

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

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

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

Ладно, давайте предметнее. Вот у меня есть сущности: новости, тизеры. Есть к этим новостям всякие метрики. Стоит ли физически выделять в отдельную папку метрики или же закапывать там же где и сущности, т.е. в тех же папках???

у тебя все сущности лежат в одной папке?

а если ты хочешь чтобы это потом реюзали

нет, конечно

или они разложены модульно?

Ddd в опенсорсе по определению быть не может

в php тоже быть не может

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

типа есть корень modules

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

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

Естть еще отдельные метрики, которые пишутся вместе с сущностными :)

в php тоже быть не может

язык роли не играет

если там в процессе будет еще и меняться какой-нибудь ридми типа с тз - будет более-менее неплохо

Естть еще отдельные метрики, которые пишутся вместе с сущностными :)

но, я так понимаю, это разные метрики?

но, я так понимаю, это разные метрики?

типа, пишутся в отдельные таблицы

у тебя все сущности лежат в одной папке?

только вот не все что пишется в базу это сущности!

только вот не все что пишется в базу это сущности!

именно

и не все что пишется в базу должно лежать в папочке model

тут надо понимать нюансы реализации а метрики новостей пишутся к новостям?

и не все что пишется в базу должно лежать в папочке model

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

папочка model к базе аще отношения не имеет

тут надо понимать нюансы реализации а метрики новостей пишутся к новостям?

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

папочка model к базе аще отношения не имеет

а вдруг святой active record

а вдруг святой active record

сжечь

а вдруг святой active record

и на кол

давай свой вариант для этих штук)

зато быстро, .... ну хотя бы в начале

зато быстро, .... ну хотя бы в начале

@fesor призываю тебя с лекцией на счет быстро. Как-то выясняли, что не очень :)

зато быстро, .... ну хотя бы в начале

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

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

я знаю же это сарказм)) что со временем все медленней и медленней

забег на короткую дистанцию

и примеры в инете и в большинстве фреймворков ar по умолчанию

давай свой вариант для этих штук)

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

и актив рекорд можно изолировать безболезненно. Другой вопрос, нахера он тогда нужен)

давай свой вариант для этих штук)

с DDD сущностями то понятно, чтобы к базе ходить хватит и сервиса типа table data gateway

DDD - это прямо как триггер слово

вентилятор начинает расскручиваться))

с DDD сущностями то понятно, чтобы к базе ходить хватит и сервиса типа table data gateway

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

DDD - это прямо как триггер слово

ещё есть "микросервисы")

Dai Duraku Dorogu

ещё есть "микросервисы")

сеттеры

И адская смесь: А можно ли с помощью ДДД делать сеттеры в микросервисах.

Бам

ddd, микросервисы, докер, аркестарция, devops, agile, что еще за крутые базворды знаем? event sourcing, cqrs ...

и актив рекорд можно изолировать безболезненно. Другой вопрос, нахера он тогда нужен)

зачем его изолировать?

ddd, микросервисы, докер, аркестарция, devops, agile, что еще за крутые базворды знаем? event sourcing, cqrs ...

cqrs, event sourcing, actor model. Девочки ведутся

зачем его изолировать?

что бы говно с ним н жрать потом

cqrs, event sourcing, actor model. Девочки ведутся

я дописал чуть раньше))

Бам

в микросервисах для мадженты, написанных на yii2

что бы говно с ним н жрать потом

ну так может его изначально не использовать?)

ну так может его изначально не использовать?)

это и была основная мысль)

фаулер же писал в книге

ну так может его изначально не использовать?)

а как же игра в сапера

типо вот есть row data gateway

типо вот есть row data gateway

иди это юишникам расскажи) можешь ещё ларавельщикам лецию накинуть)

кстате проведите ревью мое либе )))

если разделять то сделаете свой дата-мапер

ERROR: S client not available

и звездочку поставьте если код хороший)))

хочу чтобы ей пользовались люди

иди это юишникам расскажи) можешь ещё ларавельщикам лецию накинуть)

я бы послушал :)

хочу чтобы ей пользовались люди

опасная либа, я бы не пользовался)

чтобы было проще возьмите "чуть логики" и добавьте в row data gateway

хочу чтобы ей пользовались люди

в чем + от других?

опасная либа, я бы не пользовался)

ну я с твоим замечанием насчет mixed согласен но к сожалению увы интерфейс контейнера таков

в чем + от других?

ну если объективно 1. Любую другую либу можно сделать провайдером в мою 2. Мне нравиться тот синтаксис описания зависимостей и просто и отсутствие лишнего булшита 3. Автоматическая конфигурация по параметрам конструктора в большинстве либ уже есть (я хочу в следующий релиз кэширование сюда добавить по работе с рефлекшен)

ну и лично для меня 4. ЧСВ что это моя либа, но там мало кода и понять его довольно просто и плюс 100% code coverage )))

ну если объективно 1. Любую другую либу можно сделать провайдером в мою 2. Мне нравиться тот синтаксис описания зависимостей и просто и отсутствие лишнего булшита 3. Автоматическая конфигурация по параметрам конструктора в большинстве либ уже есть (я хочу в следующий релиз кэширование сюда добавить по работе с рефлекшен)

1. зачем? 2. тебе нравится 3. не преимущество 4. только если так!

1. зачем? 2. тебе нравится 3. не преимущество 4. только если так!

2 - может кому то еще понравиться? 3 - для pimple преимущество (для php-di, или symfony di не преимущество смотря с чем сравнивать)

у моей либы аще плюсов нет) сложна и нипанятна)

а ещё человеки зачем-то на демку звёздочки тыкают)

Что за либа то? Скучно читать срач и быть не в теме. Киньте ссылкой плиз)

а ещё человеки зачем-то на демку звёздочки тыкают)

потому что не понятно. А если не понятно, значит круто априори

Что за либа то? Скучно читать срач и быть не в теме. Киньте ссылкой плиз)

https://github.com/smpl/mydi

потому что не понятно. А если не понятно, значит круто априори

потом посмотреть )))

а звездочка чтобы не забыть, но успешно забывается

там на картинку если тыкнуть видео документация, ноухау)

потому что не понятно. А если не понятно, значит круто априори

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

самое сложное это писать мануал

самое сложное это писать мануал

понятный мануал

понятный мануал

это почти анриал

А как можно быстро посмотреть знаение свойства объекта в режиме дебага в шторме?

alt + f8

название объекта

и он его структуру выведет

или alt+shift+8

например

alt+f8 $this enter

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