Пришел почти к такому же виду после нескольких лет работы с laravel, очень похожее получилось. И на самом деле схема очень удачная на мой взгляд. Но советую посмотреть в сторону вынесения бизнес логики в директорию source, что бы можно было отделить сервисы к примеру от неймспейса приложения и тогда в контроллерах use будет выглядеть след. образом use Source\Modules\User\CreateService;. Это первый момент а второй момент, в файлах директории source сразу будут видны зависимости из app и там можно пресечь протекание, не нужных зависимостей в бизнес логику, или допустим исключить попадание реквестов в бизнес логику. Но поработав с такими схемами пришел к выводу 1 - накопилось много кода на разных проектах который нужно выносить в отдельные репозитории, например абстрактный репозиторий там есть что сделать на самом деле, 2 - появились мысли о том как сделать еще более независимой логику, а это уже переход на подобие DDD, но вот пока не доберусь до реализации. А вообще радует что у кого то схожие мысли появились)))
В целом уже достали эти курсы и это реально бесить уже начинает. Вообще IT отрасль наверное первая кто страдает от них. Ни в одной другой такого кошмара нет, я не видел рекламы - "Стань врачом за 9 месяцев и делай пластические операции", "Стань юристом за 3 месяца и выигрывай суды у Эпл", "Стань архитектором промышленных сооружений за 6 мес.". Просто какое то отвратительное неуважение к людям которые закончили колледжи и университеты, люди которые реально учились что то делали, понятия не имели что их профессию и их дело начнут вот так вот принижать. Хер*** на твои 5 лет мучений, и твои 2 диплома и 20 курсовых... будешь сидеть за одним столом с джуном который вчера вагоны разгружал а через год когда ты его натаскаешь мы втихаря ему сделаем зп как у тебя.
Осмелюсь предположить))) По описанию классическое манагерское MVP, когда нет четкого плана как выглядит продукт целиком, сначала скорее всего какую то фичу сделали или несколько, а потом пошли правки, правки, правки ну и на 150 итерации всем уже плевать было как что там работает, и начался dependency hell, и каждый релиз создавал новые баги, и тут и вспоминают о микросервисах, в надежде на то что код изолируется и баги уйдут)))
Попробуйте купить по левым паспортным данным билеты на самолет/поезд, или на левые паспортные данные оформить договор на поставку газа в газпроме, в страховой тоже... я не думаю что это вообще возможно, а если даже получиться то, закончится эта история не очень хорошо. Зато вот утечка данных в современных реалиях уже ровна 99%.
Первый кейс это баг или уязвимость обычного по, даже одна копия винды пиратской может бед натворить, второй кейс - это инсайдеры, в любой момент один из сотрудников может либо украсть данные либо собственноручно скомпроментировать их. Самое печальное что потенциально от кражи данных не застрахованы даже крупные кампании.
В целом пора запретить кофейням и магазинам собирать данные в любом виде, а карты лояльности выдавать как есть без привязок к данным.
Самый банальный пример когда эти данные были актуальны это отправка конверсий на facebook, при совершении покупки, хеш номера телефона отправлялся на fb, а тот в свою очередь сверял, видел ли пользователь рекламу. Это одни из множества примеров. Но это еще более менее гуманно, такие вещи хотя бы помогают оценивать офлайн покупки и на сколько эффективно работает реклама.
НО они же сливают эти телефоны, причем даже сделали инструменты которые позволяют обойти законы о защите персональных данных. И больше всего бесит, когда на кассах начинаются срачь из за номера телефона или емейла, без номера телефона мне однажды не хотели продавать кофе, билеты на жд вокзале, пару дней назад я ругался с менеджером местечкового газпрома, им край нужен был мой емейл, это все делается настолько навязчиво что чаще всего уже доходит вплоть до отказа в обслуживании, это уже жесть какая то. И очень часто все эти разборки портят настроение.
И еще один момент, некоторые кампании становятся хитрее, в одной аптеке я был свидетелем валидации номера телефона путем звонка и проговаривания кода, и этот код нужно повторить кассиру.
И сразу почему меня тригирит так, по работе я общаюсь в месседжерах, вне работы с близкими людьми я разговариваю голом в месседжерах, и выходит что каждый месяц я оплачиваю связь для того что бы получать по 10 спам звонков в день - это жесть, я уже ненавижу свой телефон.
Эти вещи актуальны для всех видов проектов, особенно чаще начинаешь вспоминать про эти принципы когда пытаешься написать юнит тесты, там ошибки проектирования всплывают моментально и становиться больно смотреть на код. Например начинаешь понимать что лучше использовать DI потому что так легче мокать какие то объекты, самое банальное это когда пишется какая то интеграция с внешним апи, и используется Guzzle, и вот в тестах становиться вопрос особенно остро, как засунуть в свой сервис объект Guzzle, так что бы были заранее замоканы ответы в нем, да еще во всех возможных вариантах, вот тут и начинает большую роль играть SOLID. Можно и без тестов да, но если у вас есть какая то интеграция с платежными системами то лучше что бы тесты были.
Логика проста, причина такого подхода это изолироваться от немспейса самого фреймворка, и это стремление отгородить именно "бизнес логику", по сути можно и в App все складывать, а можно просто создать директорию и дописать одну строчку в композере и будет отдельный неймспейс под бизнес логику. Одна из причин почему я так когда то сделал, я хотел избежать протечек фреймворка в бизнес логику, просто что бы не один одна строчка с App/... не попала в логику, правда вот до доменов все никак не доберусь но идея в примере классная, один из плюсов такого подхода, если надо будет как то отделить код от проекта то как минимум меньше времени уйдет, не будет зависимостей у других доменов, так и у самого домена.
Когда речь заходит за архитектуру любого ПО лучше прибегать к средствам визуального моделирования UML, как минимум диаграмма классов, круто когда есть диаграмма последовательностей. Это не делает красивее статью, это делает ее понятнее, если посмотреть на статьи по паттернам там везде прилагают схемы.
Корпоративный тоталитаризм в действии. Позже они заставят сотрудников поставить другие продукты сбера уже у себя дома, со сбермобайлом до кучи. А сотрудника заставят подписать договор о разрешении сбора данных. В итоге сбер будет знать все о своем сотруднике, что смотрит, когда выгуливает собаку и где, и даже какую туалетную бумагу использует. Страшное будущее нас ждет.
Пришел почти к такому же виду после нескольких лет работы с laravel, очень похожее получилось. И на самом деле схема очень удачная на мой взгляд. Но советую посмотреть в сторону вынесения бизнес логики в директорию source, что бы можно было отделить сервисы к примеру от неймспейса приложения и тогда в контроллерах use будет выглядеть след. образом use Source\Modules\User\CreateService;. Это первый момент а второй момент, в файлах директории source сразу будут видны зависимости из app и там можно пресечь протекание, не нужных зависимостей в бизнес логику, или допустим исключить попадание реквестов в бизнес логику. Но поработав с такими схемами пришел к выводу 1 - накопилось много кода на разных проектах который нужно выносить в отдельные репозитории, например абстрактный репозиторий там есть что сделать на самом деле, 2 - появились мысли о том как сделать еще более независимой логику, а это уже переход на подобие DDD, но вот пока не доберусь до реализации. А вообще радует что у кого то схожие мысли появились)))
В целом уже достали эти курсы и это реально бесить уже начинает. Вообще IT отрасль наверное первая кто страдает от них. Ни в одной другой такого кошмара нет, я не видел рекламы - "Стань врачом за 9 месяцев и делай пластические операции", "Стань юристом за 3 месяца и выигрывай суды у Эпл", "Стань архитектором промышленных сооружений за 6 мес.". Просто какое то отвратительное неуважение к людям которые закончили колледжи и университеты, люди которые реально учились что то делали, понятия не имели что их профессию и их дело начнут вот так вот принижать. Хер*** на твои 5 лет мучений, и твои 2 диплома и 20 курсовых... будешь сидеть за одним столом с джуном который вчера вагоны разгружал а через год когда ты его натаскаешь мы втихаря ему сделаем зп как у тебя.
Осмелюсь предположить))) По описанию классическое манагерское MVP, когда нет четкого плана как выглядит продукт целиком, сначала скорее всего какую то фичу сделали или несколько, а потом пошли правки, правки, правки ну и на 150 итерации всем уже плевать было как что там работает, и начался dependency hell, и каждый релиз создавал новые баги, и тут и вспоминают о микросервисах, в надежде на то что код изолируется и баги уйдут)))
Попробуйте купить по левым паспортным данным билеты на самолет/поезд, или на левые паспортные данные оформить договор на поставку газа в газпроме, в страховой тоже... я не думаю что это вообще возможно, а если даже получиться то, закончится эта история не очень хорошо. Зато вот утечка данных в современных реалиях уже ровна 99%.
Первый кейс это баг или уязвимость обычного по, даже одна копия винды пиратской может бед натворить, второй кейс - это инсайдеры, в любой момент один из сотрудников может либо украсть данные либо собственноручно скомпроментировать их. Самое печальное что потенциально от кражи данных не застрахованы даже крупные кампании.
В целом пора запретить кофейням и магазинам собирать данные в любом виде, а карты лояльности выдавать как есть без привязок к данным.
Самый банальный пример когда эти данные были актуальны это отправка конверсий на facebook, при совершении покупки, хеш номера телефона отправлялся на fb, а тот в свою очередь сверял, видел ли пользователь рекламу. Это одни из множества примеров. Но это еще более менее гуманно, такие вещи хотя бы помогают оценивать офлайн покупки и на сколько эффективно работает реклама.
НО они же сливают эти телефоны, причем даже сделали инструменты которые позволяют обойти законы о защите персональных данных. И больше всего бесит, когда на кассах начинаются срачь из за номера телефона или емейла, без номера телефона мне однажды не хотели продавать кофе, билеты на жд вокзале, пару дней назад я ругался с менеджером местечкового газпрома, им край нужен был мой емейл, это все делается настолько навязчиво что чаще всего уже доходит вплоть до отказа в обслуживании, это уже жесть какая то. И очень часто все эти разборки портят настроение.
И еще один момент, некоторые кампании становятся хитрее, в одной аптеке я был свидетелем валидации номера телефона путем звонка и проговаривания кода, и этот код нужно повторить кассиру.
И сразу почему меня тригирит так, по работе я общаюсь в месседжерах, вне работы с близкими людьми я разговариваю голом в месседжерах, и выходит что каждый месяц я оплачиваю связь для того что бы получать по 10 спам звонков в день - это жесть, я уже ненавижу свой телефон.
Эти вещи актуальны для всех видов проектов, особенно чаще начинаешь вспоминать про эти принципы когда пытаешься написать юнит тесты, там ошибки проектирования всплывают моментально и становиться больно смотреть на код. Например начинаешь понимать что лучше использовать DI потому что так легче мокать какие то объекты, самое банальное это когда пишется какая то интеграция с внешним апи, и используется Guzzle, и вот в тестах становиться вопрос особенно остро, как засунуть в свой сервис объект Guzzle, так что бы были заранее замоканы ответы в нем, да еще во всех возможных вариантах, вот тут и начинает большую роль играть SOLID. Можно и без тестов да, но если у вас есть какая то интеграция с платежными системами то лучше что бы тесты были.
Логика проста, причина такого подхода это изолироваться от немспейса самого фреймворка, и это стремление отгородить именно "бизнес логику", по сути можно и в App все складывать, а можно просто создать директорию и дописать одну строчку в композере и будет отдельный неймспейс под бизнес логику. Одна из причин почему я так когда то сделал, я хотел избежать протечек фреймворка в бизнес логику, просто что бы не один одна строчка с App/... не попала в логику, правда вот до доменов все никак не доберусь но идея в примере классная, один из плюсов такого подхода, если надо будет как то отделить код от проекта то как минимум меньше времени уйдет, не будет зависимостей у других доменов, так и у самого домена.
Конечно, это скорее рекомендательный характер, в любом случае спасибо)
Когда речь заходит за архитектуру любого ПО лучше прибегать к средствам визуального моделирования UML, как минимум диаграмма классов, круто когда есть диаграмма последовательностей. Это не делает красивее статью, это делает ее понятнее, если посмотреть на статьи по паттернам там везде прилагают схемы.
Корпоративный тоталитаризм в действии. Позже они заставят сотрудников поставить другие продукты сбера уже у себя дома, со сбермобайлом до кучи. А сотрудника заставят подписать договор о разрешении сбора данных. В итоге сбер будет знать все о своем сотруднике, что смотрит, когда выгуливает собаку и где, и даже какую туалетную бумагу использует. Страшное будущее нас ждет.
Речь идет об этом https://www.google.ru/search?q=asdadsddddddddddddddddddddddddddddddddddddddddd
На странице будет видно "По запросу asdadsddddddddddddddddddddddddddddddddddddddddd ничего не найдено. "