А
Это и еноту понятно, что фасад является фасадом от того, что находится непосредственно внутри класса
Чо?
Size: a a a
2020 November 24
SK
паттерн Репозиторий в основном про write операции. Про некое хранилище сущностей. А тут оставлена только его read часть. Это очень важное различие.
Тут я думаю, все же зависит от того, в рамках какого подхода мы разговариваем.
Если мы говорим про cqrs, то безусловно.
Если мы говорим про классический ддд, то и выборка данных может происходить в репозитерии.
Имхо
Если мы говорим про cqrs, то безусловно.
Если мы говорим про классический ддд, то и выборка данных может происходить в репозитерии.
Имхо
A
Sergey Kiryakov
Тут я думаю, все же зависит от того, в рамках какого подхода мы разговариваем.
Если мы говорим про cqrs, то безусловно.
Если мы говорим про классический ддд, то и выборка данных может происходить в репозитерии.
Имхо
Если мы говорим про cqrs, то безусловно.
Если мы говорим про классический ддд, то и выборка данных может происходить в репозитерии.
Имхо
ддд и репозитории - это вообще вещи не связанные
A
ну прям вот совсем )
A
никакой связи
ПФ
Это я к тому, что ClassFacade не является фасадом только потому, что там в названии фигурирует это слово. Laravel Facade никак не может являться фасадом из под коробки, он лишь предлагает удобный интерфейс для реализации этого паттерна. А то, как уже реализовывать сложность систем и подсистем уже решать разработчику
Я думаю они это сделали, чтобы каждый не придумывал свой вариант решения и добавил в качестве печеньки callStatic
Я думаю они это сделали, чтобы каждый не придумывал свой вариант решения и добавил в качестве печеньки callStatic
SK
никакой связи
Ну вот я опять мысли не сформулировал)
A
cqrs и ddd - очень близкие понятия и ддд приводит потихоньку к cqrs по мере развития
A
потому что трудно удерживать read и write логику вместе
A
я же говорю про Eloquent.
A
и там паттерн репозиторий в чистом виде просто бесполезен
A
хотя ддд от cqrs так же далёк как и от репозиториев ) ддд - это некая идея. а все эти репозитории и cqrs - лишь детали реализации. несущественные для этой идеи
RV
хотя ддд от cqrs так же далёк как и от репозиториев ) ддд - это некая идея. а все эти репозитории и cqrs - лишь детали реализации. несущественные для этой идеи
слишком часто прост вспоминают это в статейках вида ДДД за 15 минут =)
и сначала действительно может показатся что тактический ДДД это вся суть
и сначала действительно может показатся что тактический ДДД это вся суть
A
слишком часто прост вспоминают это в статейках вида ДДД за 15 минут =)
и сначала действительно может показатся что тактический ДДД это вся суть
и сначала действительно может показатся что тактический ДДД это вся суть
ага. а достаточно почитать Эванса, так сразу понятно, что чел вообще избегает говорить о чём либо, кроме классов, которые решают доменную логику.
RV
ага. а достаточно почитать Эванса, так сразу понятно, что чел вообще избегает говорить о чём либо, кроме классов, которые решают доменную логику.
ну там еще читать много нужно, а в статейках "проще все"
даже Domain Driven Design Quickly на 200 страниц почти, правда там сразу говориться что ДДД не про код)
даже Domain Driven Design Quickly на 200 страниц почти, правда там сразу говориться что ДДД не про код)
A
ой я с большим трудом Эванса дочитал ) он с самого начала бьёт примером про рейсы этих кораблей... и это блин не корзина инет-магазина, мягко говоря
A
есть ли что-то небезопасное в том, что на продакшене будет сделан composer install, а не composer install —no-dev?
A
не стоит )
RV
есть ли что-то небезопасное в том, что на продакшене будет сделан composer install, а не composer install —no-dev?
смотря что стоит в дев зависимостях
часто там всякие отладчики и дебаг бары
поэтому если кто-то не верно настроил их или поставил не верные конфигы можно много чего показать
часто там всякие отладчики и дебаг бары
поэтому если кто-то не верно настроил их или поставил не верные конфигы можно много чего показать