Спасибо за ролик! Подход с коммуникаторами очень похож на подход API + Adapter в чистой (слоеной) архитектуре Было бы очень интересно посмотреть пример проекта с изолированными модулями
3:03 имеют ли смысл эти интерфейсы в отрыве от соответствующего модуля? 4:15 "взаимодействуем исключительно с помощью интерфейса и публичных методов что нам доступны" 8:17 А как же open/closed? Мы оставляем публичный метод которым нельзя пользоваться и старший разраб должен это контролировать?
В комментариях вы говорите, что выбирая Laravel, надо быть готовым к компромисам. Отсюда делаю выводы, что сложные проекты делать на Laravel нецелесообразно. Тогда зачем выдумывать велосипед, если уже есть архитектура от разработчиков фреймворка? Как минимум, не будет страданий при поддержке. Наверное можно сделать велосипед в пакете. Туда никто не полезет.
Я к такому же пришёл в итоге, только да, как и ниже кто-то писал у меня всё приложение зависит от папки с контрактами. И обмазал это php insight + deptrac Но тут стучится проблема Eloquent. Чтобы изолировать модели базы данных от слоя управления мы их очевидно вешаем на интерфейсы А так как в пыхе нет интерфейсов на публичные свойства, приходится либо костылями (контракт магического геттера + phpDoc), либо гет методами лечить проблему. В первом случае мы открываем знания о то что можно записать в поле модели в слое управления, что запрещено архитектурно Во втором случае мы ломаем архитектурную концепцию eloquent и начинаем делать чуждые ей геттеры Плюс в системе с единой моделью базы данных очень быстро ключевые модели обрастут деталями других модулей То есть мы сразу ставим правило что модели должны быть анемичными(иначе теряется смысл модульности), а вся логика уйдёт в севисы доменного слоя. И тут ещё приходит проблема, что есть слой модуля, а есть доменный слой и они имеют разное предназначение. Слой модуля - это слой управления доменом. У этого слоя свои сервисы и свои модели(дто) Доменный же слой ультратонкий в котором всё что есть это модели(не eloquent, а в отдельных случаях большого домена - кастомные, которые не зависят от бд) и сервисы Единственная зависимость домена - контракты и модель eloquent. Но мы так же можем архитектурно убрать проблему сохранения моделей не в том месте и создание странных ситуаций тем, что повесим зависимость домена на разбитый контракт модели на write и read-интерфейсы. В общем, та модульность которую ты показал это лишь малая часть огромной работы которую нужно провести для борьбы с хаосом завимостей и нарушения ответственности слоёв. И то не факт что это поймут в боевом проекте. Я такое экспереентирую только в пет проектах. Потому что у меня есть печальный опыт когда боевой проект, написанный с нуля, через полтора года закрылся от крайне высоких затрат на поддержку оверинжиниринга так как никто кроме архитектора не понял написанного и поломал быстро проект до неподдерживаемого состояния.
@@CutCodeRu по-сути так и есть. Чем больше ты ломаешь архитектуру laravel и пытаешься сделать её чище чем ближе ты к симфони. Проблема больше кроется в том, что ларавель не предназначен быть чистым по изначальной задумке) Нужно много компромиссов как с архитектурой так и с потенциальными разработчиками. И где-то на грани этого балансировать. Вот тебе пример, чувак в нарушение слоёв вызывает в ресурсе бизнес-действие. Как от этого защититься? Повесить зависимость слоя управления от контрактов + php stan. Сломать это можно, но на ревью такой костыль будет кричащим. Как это реализовать иначе? Делать viewModel слоя управления и кастить из элоквент во viewModel. Цена поддержки мега высокая. Цена контракта будет минимальной, но если мы делаем контракт с магическим геттером то автоматически лишаем себя возможности передавать наверх простые ДТО. А иначе придётся писать геттеры и ломать концепцию eloquent... Чтобы сделать лару чистой придётся заключить очень много компромиссов. Скажем так, архитектурные скилы типового разработчика на ларавель на порядок ниже симфониста. И я сейчас, например, часто сталкиваюсь с тем, что разрабы не понимают элементарных архитектурных паттернов, отличных от стандартных лары. И не понимают почему некоторые паттерны лары не жизнеспособны в большом проекте.
Странный подход, не ясно зачем крутить эти интерфейсы, как по мне лишняя абстракция. Если модуль не доступен, то и интерфейсы работать не будут, а если доступен модуль, то смысл городить этот огород. Модульная система хорошо реализована в Yii2, тут по этому ролику понять ценность предлагаемого автором невозможно.
Ролик в студию. Ты просто мастер объяснять. Постоянно смотрю даже то, что знаю!😂
Благодарю)
Ждём ролик про тесты!)
🫡
Спасибо за ролик!
Подход с коммуникаторами очень похож на подход API + Adapter в чистой (слоеной) архитектуре
Было бы очень интересно посмотреть пример проекта с изолированными модулями
Полписался. Да сними пожалуйста развернутый ролик о TDD
Классный ролик! Очень полезный материал!👍
🤗
🙌
Очень прошу запиши такой ролик! только что
👌
Как полюбить писать тесты?
расскажу)
Ждем TDD
👀
3:03 имеют ли смысл эти интерфейсы в отрыве от соответствующего модуля?
4:15 "взаимодействуем исключительно с помощью интерфейса и публичных методов что нам доступны"
8:17 А как же open/closed? Мы оставляем публичный метод которым нельзя пользоваться и старший разраб должен это контролировать?
Классный материал, будут интересны и другие видое в этом направлении
6:08 - интересно, но мне кажется это сложнее, чем приучить себя регулярно делать гимнастику. Особенно когда на работе есть живой тестировщик
Даешь приложение в рамках концепкии!
окай
Выглядит класно, но боюсь в комуникаторе будет срачь если приложение долгоживущие. Нужно делать коммунткаторы как можно тонкими
да проектировать нужно на старте, и модули по хорошему должны быть тонкими, но и как я говорил в начале ролика - для не сложных проектов
если долгоживущие, то можно просто РПЦ а если РПЦ то в прото файлах ты и так описываешь интерфейс сервиса
@@pavlobezdvernyi9348 угу, specification first
странный подход, но чем-то интересный. а почему в данном случае интерфейс отделен (namespace) от реализации? в чем преимущество?
в том что реализации может быть много
@@strandedinthe0737 это точно преимущество?
@@alexanderk8992 в нормальном патерне это называется порты и адаптеры
@@strandedinthe0737 я про неймспейсы.
Очень прошу запиши такой ролик!
🌟
имхо, неудачное название комуникатор.
может быть Connector, Bridge, или даже просто ...Module
Ну это уже все есть) хочется по свежее
@@CutCodeRu у меня коммуникатор только с телефонами ассоциируется.
@@silentage6310 у меня со звездными войнами)
@@silentage6310 телефоны так то тоже для общения
@@CutCodeRu давай классы тогда назовём phone :)
UserPhone
OrderPhone
DeliveryPhone
звучит! :)
В комментариях вы говорите, что выбирая Laravel, надо быть готовым к компромисам. Отсюда делаю выводы, что сложные проекты делать на Laravel нецелесообразно. Тогда зачем выдумывать велосипед, если уже есть архитектура от разработчиков фреймворка? Как минимум, не будет страданий при поддержке. Наверное можно сделать велосипед в пакете. Туда никто не полезет.
Выглядит как-будто бы просто вы одним доменом завязываетесь на фасад другого домена
По больше всего этого
ок!
Отличное видео. Я тоже так делаю. Но вместо Communicators называю просто папку Contracts.
Хехе
Ждем следующие видео на эту тему. С примерами и так далее
сделаем!
Thanks❤
🙏
Почему у тебя User.php лежит внутри модуля? Это не правильно если он используется контрактом то он должен лежать рядом с контрактами
❤
🤗
Вы просто супер жду ролик про тесты.
ок, сделаем!
Я к такому же пришёл в итоге, только да, как и ниже кто-то писал у меня всё приложение зависит от папки с контрактами.
И обмазал это php insight + deptrac
Но тут стучится проблема Eloquent.
Чтобы изолировать модели базы данных от слоя управления мы их очевидно вешаем на интерфейсы
А так как в пыхе нет интерфейсов на публичные свойства, приходится либо костылями (контракт магического геттера + phpDoc), либо гет методами лечить проблему.
В первом случае мы открываем знания о то что можно записать в поле модели в слое управления, что запрещено архитектурно
Во втором случае мы ломаем архитектурную концепцию eloquent и начинаем делать чуждые ей геттеры
Плюс в системе с единой моделью базы данных очень быстро ключевые модели обрастут деталями других модулей
То есть мы сразу ставим правило что модели должны быть анемичными(иначе теряется смысл модульности), а вся логика уйдёт в севисы доменного слоя.
И тут ещё приходит проблема, что есть слой модуля, а есть доменный слой и они имеют разное предназначение.
Слой модуля - это слой управления доменом.
У этого слоя свои сервисы и свои модели(дто)
Доменный же слой ультратонкий в котором всё что есть это модели(не eloquent, а в отдельных случаях большого домена - кастомные, которые не зависят от бд) и сервисы
Единственная зависимость домена - контракты и модель eloquent. Но мы так же можем архитектурно убрать проблему сохранения моделей не в том месте и создание странных ситуаций тем, что повесим зависимость домена на разбитый контракт модели на write и read-интерфейсы.
В общем, та модульность которую ты показал это лишь малая часть огромной работы которую нужно провести для борьбы с хаосом завимостей и нарушения ответственности слоёв.
И то не факт что это поймут в боевом проекте. Я такое экспереентирую только в пет проектах.
Потому что у меня есть печальный опыт когда боевой проект, написанный с нуля, через полтора года закрылся от крайне высоких затрат на поддержку оверинжиниринга так как никто кроме архитектора не понял написанного и поломал быстро проект до неподдерживаемого состояния.
@@ИльяСорокин-д9ц рассказ о том как мы пришли к doctrine) а так со всем согласен, спасибо за такой комментарий!
@@CutCodeRu по-сути так и есть. Чем больше ты ломаешь архитектуру laravel и пытаешься сделать её чище чем ближе ты к симфони.
Проблема больше кроется в том, что ларавель не предназначен быть чистым по изначальной задумке)
Нужно много компромиссов как с архитектурой так и с потенциальными разработчиками.
И где-то на грани этого балансировать.
Вот тебе пример, чувак в нарушение слоёв вызывает в ресурсе бизнес-действие.
Как от этого защититься? Повесить зависимость слоя управления от контрактов + php stan. Сломать это можно, но на ревью такой костыль будет кричащим.
Как это реализовать иначе? Делать viewModel слоя управления и кастить из элоквент во viewModel. Цена поддержки мега высокая.
Цена контракта будет минимальной, но если мы делаем контракт с магическим геттером то автоматически лишаем себя возможности передавать наверх простые ДТО.
А иначе придётся писать геттеры и ломать концепцию eloquent...
Чтобы сделать лару чистой придётся заключить очень много компромиссов.
Скажем так, архитектурные скилы типового разработчика на ларавель на порядок ниже симфониста.
И я сейчас, например, часто сталкиваюсь с тем, что разрабы не понимают элементарных архитектурных паттернов, отличных от стандартных лары.
И не понимают почему некоторые паттерны лары не жизнеспособны в большом проекте.
@@ИльяСорокин-д9ц да все верно и выбирая ларавел надо быть готовым к куче компромиссов
Очень прошу, запиши такой ролик!
ок!
а как в такой модульной системе widart/laravel-modules придерживаться изоляции?
также
Очень прошу ролик про интерфейсы, и про то, как их можно связывать с классами, и как использовать дальше в проектах!
сделаем!
Недрочибельно.
Вы просто не старались!
@@CutCodeRu В том-то и дело, что старался((( Очень старался((( И так и сяк. Ну ни как.
Большое спасибо!
🙌
👌
Странный подход, не ясно зачем крутить эти интерфейсы, как по мне лишняя абстракция. Если модуль не доступен, то и интерфейсы работать не будут, а если доступен модуль, то смысл городить этот огород. Модульная система хорошо реализована в Yii2, тут по этому ролику понять ценность предлагаемого автором невозможно.
пожалуйста сделайте ролик с тдд и более подбробный ролик на реальном простом примере модулей
запланировал