Иногда складывается впечатление, что некоторые живут в мире единорогов, а не в реальном мире.
если так получилось, что вы можете выбирать архитектуру с нуля и поддерживать этот проект на всех этапах его жизни, то могу только поздравить. но не у всех так. У обычных разработчиков в большинстве случаев это с точностью до наоборот, т.е. приходится жить в тем что есть. Единственные исключения, когда реально повезло или когда разработчик специализируется на этом. Это "гуру" которые приходят на старте проекта лобают "архитектуру", записывают в резюме и сваливают в другой стартап, на большую ставку. Главное свалить вовремя и "после меня хоть потоп"
))
Но иногда нет возможности менять архитектуру проекта, иногда нет возможности выкинуть элоквент или другую подобную хрень (и это не потому что не хочется, а потому что найти разработчиков под популярные библиотеки тупо проще и дешевле), и когда использование Write Models находится в одном файле c использованием Read Models (таки да, они могут быть вместе, не часто, но довольно стабильно).
И кстати здесь на форуме просто обожают передергивать факты. Сразу почему-то уперлись в модели, но не всегда проблема с моделями - есть Entity, Service, Config, Option и т.д. и т.п. Модель это типичный пример, при использовании популярных библиотек/фреймфорков при написании кода по официальным гайдам. Т.е. надо понимать если разработчик фреймворка предоставляет какие-то гайды, то скорее всего большая часть разработчиков будет делать именно так. Неважно насколько это хорошо и плохо - это уже будет статистика и надо с этим как-то мириться.
Все программирование это поиск компромиссов и нет серебряной пули. Так вот эта тема как раз попытка обсуждения компромисса, а не серебрянной пули.
Просто я заметил что после введения неймспейсов именование классов превратилось в больший треш чем было до введения. Запихнуть в короткое имя класса практически полное имя/путь класса - это уже норма и печальная статистика.
Т.е. если раньше было Vendor_Super_Puper_Duper_Class, то сейчас будет \Vendor\Super\Puper\Duper\SuperPuperDuperClass. И разница при чтении кода не сильно большая между Vendor_Super_Puper_Duper_Class и SuperPuperDuperClass (одинаково уебищно смотрится). К тому же когда класс встречается разово (например в phpdoc-е), то выносить его в use тупо нет смысла и по полному имени \Vendor\Super\Puper\Duper\SuperPuperDuperClass это вообще треш с точки зрения читабельности.
И это придуманый пример наименования класса, в реальности все значительно печальнее (длинее и страшнее).
Практически никто не используется частичные use, да что говорить тупо нет инструментов в ide удобного их использования, хотя это могло бы решить проблему.
P.S. Все-таки интересно посмотреть на структуру реально большого проекта с большими bounded context, как там именуют и разбивают классы.
если так получилось, что вы можете выбирать архитектуру с нуля и поддерживать этот проект на всех этапах его жизни, то могу только поздравить. но не у всех так. У обычных разработчиков в большинстве случаев это с точностью до наоборот, т.е. приходится жить в тем что есть. Единственные исключения, когда реально повезло или когда разработчик специализируется на этом. Это "гуру" которые приходят на старте проекта лобают "архитектуру", записывают в резюме и сваливают в другой стартап, на большую ставку. Главное свалить вовремя и "после меня хоть потоп"
))Но иногда нет возможности менять архитектуру проекта, иногда нет возможности выкинуть элоквент или другую подобную хрень (и это не потому что не хочется, а потому что найти разработчиков под популярные библиотеки тупо проще и дешевле), и когда использование Write Models находится в одном файле c использованием Read Models (таки да, они могут быть вместе, не часто, но довольно стабильно).
И кстати здесь на форуме просто обожают передергивать факты. Сразу почему-то уперлись в модели, но не всегда проблема с моделями - есть Entity, Service, Config, Option и т.д. и т.п. Модель это типичный пример, при использовании популярных библиотек/фреймфорков при написании кода по официальным гайдам. Т.е. надо понимать если разработчик фреймворка предоставляет какие-то гайды, то скорее всего большая часть разработчиков будет делать именно так. Неважно насколько это хорошо и плохо - это уже будет статистика и надо с этим как-то мириться.
Все программирование это поиск компромиссов и нет серебряной пули. Так вот эта тема как раз попытка обсуждения компромисса, а не серебрянной пули.
Просто я заметил что после введения неймспейсов именование классов превратилось в больший треш чем было до введения. Запихнуть в короткое имя класса практически полное имя/путь класса - это уже норма и печальная статистика.
Т.е. если раньше было Vendor_Super_Puper_Duper_Class, то сейчас будет \Vendor\Super\Puper\Duper\SuperPuperDuperClass. И разница при чтении кода не сильно большая между Vendor_Super_Puper_Duper_Class и SuperPuperDuperClass (одинаково уебищно смотрится). К тому же когда класс встречается разово (например в phpdoc-е), то выносить его в use тупо нет смысла и по полному имени \Vendor\Super\Puper\Duper\SuperPuperDuperClass это вообще треш с точки зрения читабельности.
И это придуманый пример наименования класса, в реальности все значительно печальнее (длинее и страшнее).
Практически никто не используется частичные use, да что говорить тупо нет инструментов в ide удобного их использования, хотя это могло бы решить проблему.
P.S. Все-таки интересно посмотреть на структуру реально большого проекта с большими bounded context, как там именуют и разбивают классы.
