Про анемичные модели. Тут пока до конца не ясно, надо ли в доменную сущность пихать бизнес логику или нет. Лично я больше сторонник того, чтобы вынесли работу с сущностями в сервисы.
По поводу VO я отвечал в комментариях паблике ВК. Nullable Object позволяет "стабильнее" и однозначней использовать объекты. Дополнительный null тип будет вводить уже меньшую степень "объектности" и двойственности. Поэтому, при подходе максимального использования объектов NULL не вписывается адекватно. Помимо этого в isNull я могу зашить логику "а что такое отсутствие" тем самым "спрятав" это в объект.
Про свойства. Я считаю, что все свойства должны быть приватными или защищёнными. Публичные свойства доступны только для редактирования из вне. Геттеры и сеттеры - та же логика, что я описал выше про isNull.
В будущей статье, которая есть в ВК, были проведены работы по рефакторингу. По стандарту PSR можно использовать Interface в конце. А еще выделение Shared моментов в VO.
А ещё вместо PSR-2/12 лучше PER-2 использовать.
Чем?
А ещё не хватает хотя бы кратенькой ремарки в чём прикол анемичных энтитей. Я не говорю что это плохо, сам считаю что анемичные легче и практичнее, но всё же многие считают это плохой практикой и даже антипаттерном.
В проекте на данный момент не предусматривается изменение, лишь вывод. Исходя из этого, нет необходимости в создании методов изменения сущности
А ещё нулевой даты не существует: RacerDateOfBirth::getNull() возвращает явно некорректное и недопустимое состояние.
Этим никто пользоваться не будет, поскольку у нас есть просто факт VO без значений. И эти нули нужны просто для заполнения VO. Процесс взаимодействия будет строиться через isNull, где что-то будет не отображаться и так далее.
Я прям представляю, как автор сидит слюнями и соплями кидается пока пишет статью в углу комнаты, обняв ноги и катается туда-сюда 🤣
Если верить статье, то да, ты нашел тот самый кейс с безопасностью. А если серьёзно, то включай все этапы защиты, меняй чаще пароль и будть аккуратнее в интернете.
Что же, это ваш выбор, но уйма ООП приложений PHP работают именно по какой-то архитектуре директорий, символизирующие не только слои приложения, но и namespace.
Не, ты делаешь в своем "модуле" этот слой, где повторяешь структуру, а классы в ней - адаптеры, которые используют чужие классы и мапят их на свои так, как тебе это надо. Это оптимальный вариант использования.
Например, также берем anticorruption layer и связываем все что хотим. Просто если мы были бы разными командами разработки, то напрямую ничего вашего трогать не могу. Тут цельная структура об одном и том же (контекст), так что можно использовать без проблем.
С другой стороны, никто не мешает написать адаптеры на anticorruption layer, чтобы "законно" использовать что-то "чужое"
Разница в архитектуре приложения, связанности классов, разделения логики. Например, вы обедаете на кухне, а спите в спальне. По хорошему, вы не должны обедать в спальне. Вот и такая история тут.
В папке Domain и других лежат "модули". То есть у нас как бы одно единственное приложение, которое не разделено на структуры типа Car\{App, Domain и Infrastrucutre}, а наоборот - все объединено в App, Domain и Infrastrucutre и имеет внутри то, с чем работаем. Данный подход на текущем этапе достаточен.
По поводу работы VO "разных доменов" тут получается так, что мы можем можем использовать в рамках Car все, что внутри, если нам надо использовать в Racer что-то из VO Car, то для этого формируется VO на стороне Racer, который на инфраструктурном слое парсится из CarVO -> RacerCarVO. Другой подход - прямое использование, так как по факту приложение одно и "область видимости" тоже. Вот если бы были разные структуры (описал выше), то тогда да, маппинг через anticorruption layer или что-то в таком духе.
В чём была причина отказываться от Presentation слоя
Никто не отказывался, мы просто пока не дошли до этого момента. Я же пишу в формате "живого блога". Поэтому, когда мы дойдем до запросов (а это вообще последнее, что будет), то добавим нужные слои. Но, на самом деле, это вообще не важно, так как мы будем писать команды, которые по факту будут вызываться в Presentation слое.
Вместо *.sh скриптов можно использовать composer
Дельное замечание, забыл про это совсем. Подумаю над переносом в composer.
Если поделитесь опытом, то будет очень кстати. Проект реализуется от простого к сложному, потом будет и квалификация и прочее. Пока решил сделать так, чтобы не захламлять мозг и не путаться от масштаба.
Поддживаю, но, как я понимаю, здесь идет больше посыл "как быстро уйдут старые версии из обихода". Ведь тот же гос сектор работает на сторгих сертификатах, где версия php существенно отстает от современных. В моей текущей компании (коммерческая) буквально пару недель назад обновили до 8.3. Здесь же уже другой принцип по версионности языка.
А вообще, я лично считаю, что минимальная версия сейчас должна быть 8.0. Это позволяет без проблем обновляться дальше и юзать крутые новые фичи php.
Да ну не настолько. Просто сборная солянка простых вещей, которые гугляться в первой ссылке только под свой вкус и цвет. А так-то +- полезно для краткого содержания. А вот интересную тему patch vs put не затронули.
Что означает "friendly видимость"? Тестирование приватных методов не имеет смысла, согласен. Нужно строить свой код так, чтобы входные параметры попадали на все условия приватных методов. Все будет ок, больше DI, инверсий зависимости, разнесения на слои и прочее.
Про анемичные модели. Тут пока до конца не ясно, надо ли в доменную сущность пихать бизнес логику или нет. Лично я больше сторонник того, чтобы вынесли работу с сущностями в сервисы.
По поводу VO я отвечал в комментариях паблике ВК. Nullable Object позволяет "стабильнее" и однозначней использовать объекты. Дополнительный null тип будет вводить уже меньшую степень "объектности" и двойственности. Поэтому, при подходе максимального использования объектов NULL не вписывается адекватно. Помимо этого в isNull я могу зашить логику "а что такое отсутствие" тем самым "спрятав" это в объект.
Про свойства. Я считаю, что все свойства должны быть приватными или защищёнными. Публичные свойства доступны только для редактирования из вне. Геттеры и сеттеры - та же логика, что я описал выше про isNull.
В будущей статье, которая есть в ВК, были проведены работы по рефакторингу. По стандарту PSR можно использовать Interface в конце. А еще выделение Shared моментов в VO.
Чем?
В проекте на данный момент не предусматривается изменение, лишь вывод. Исходя из этого, нет необходимости в создании методов изменения сущности
Этим никто пользоваться не будет, поскольку у нас есть просто факт VO без значений. И эти нули нужны просто для заполнения VO. Процесс взаимодействия будет строиться через isNull, где что-то будет не отображаться и так далее.
Скорее да. В контексте этого проекта сущности, которые работает только на вывод (на данный момент), не будут в ходе бизнес логики меняться.
Есть шаблон проектирования "Адаптер" посмотри.
Я прям представляю, как автор сидит слюнями и соплями кидается пока пишет статью в углу комнаты, обняв ноги и катается туда-сюда 🤣
Если верить статье, то да, ты нашел тот самый кейс с безопасностью. А если серьёзно, то включай все этапы защиты, меняй чаще пароль и будть аккуратнее в интернете.
Что же, это ваш выбор, но уйма ООП приложений PHP работают именно по какой-то архитектуре директорий, символизирующие не только слои приложения, но и namespace.
Не, ты делаешь в своем "модуле" этот слой, где повторяешь структуру, а классы в ней - адаптеры, которые используют чужие классы и мапят их на свои так, как тебе это надо. Это оптимальный вариант использования.
Например, также берем anticorruption layer и связываем все что хотим. Просто если мы были бы разными командами разработки, то напрямую ничего вашего трогать не могу. Тут цельная структура об одном и том же (контекст), так что можно использовать без проблем.
С другой стороны, никто не мешает написать адаптеры на anticorruption layer, чтобы "законно" использовать что-то "чужое"
Разница в архитектуре приложения, связанности классов, разделения логики. Например, вы обедаете на кухне, а спите в спальне. По хорошему, вы не должны обедать в спальне. Вот и такая история тут.
В папке Domain и других лежат "модули". То есть у нас как бы одно единственное приложение, которое не разделено на структуры типа Car\{App, Domain и Infrastrucutre}, а наоборот - все объединено в App, Domain и Infrastrucutre и имеет внутри то, с чем работаем. Данный подход на текущем этапе достаточен.
По поводу работы VO "разных доменов" тут получается так, что мы можем можем использовать в рамках Car все, что внутри, если нам надо использовать в Racer что-то из VO Car, то для этого формируется VO на стороне Racer, который на инфраструктурном слое парсится из CarVO -> RacerCarVO. Другой подход - прямое использование, так как по факту приложение одно и "область видимости" тоже. Вот если бы были разные структуры (описал выше), то тогда да, маппинг через anticorruption layer или что-то в таком духе.
Никто не отказывался, мы просто пока не дошли до этого момента. Я же пишу в формате "живого блога". Поэтому, когда мы дойдем до запросов (а это вообще последнее, что будет), то добавим нужные слои. Но, на самом деле, это вообще не важно, так как мы будем писать команды, которые по факту будут вызываться в Presentation слое.
Дельное замечание, забыл про это совсем. Подумаю над переносом в composer.
Если поделитесь опытом, то будет очень кстати. Проект реализуется от простого к сложному, потом будет и квалификация и прочее. Пока решил сделать так, чтобы не захламлять мозг и не путаться от масштаба.
Там еще добавили сеттеры и геттеры прям в свойства классов. Это прям тебе зайдёт)
Поддживаю, но, как я понимаю, здесь идет больше посыл "как быстро уйдут старые версии из обихода". Ведь тот же гос сектор работает на сторгих сертификатах, где версия php существенно отстает от современных. В моей текущей компании (коммерческая) буквально пару недель назад обновили до 8.3. Здесь же уже другой принцип по версионности языка.
А вообще, я лично считаю, что минимальная версия сейчас должна быть 8.0. Это позволяет без проблем обновляться дальше и юзать крутые новые фичи php.
Статья хорошая и познавательная. У меня был схожий кейс, но для документов и разных штампов на pdf. Ох там были приколы с размерами и прочее.
Вопрос по статье: а насколько это (информер графический на php) сейчас актуально?
Да ну не настолько. Просто сборная солянка простых вещей, которые гугляться в первой ссылке только под свой вкус и цвет. А так-то +- полезно для краткого содержания. А вот интересную тему patch vs put не затронули.
А где тут реклама курсов? Я увидел ссылки только на статьи, их хх и ютубы.
У меня все сломалось тогда. И Docker Desktop вообще не запускался. Поэтому, данное руководство существует.
Что означает "friendly видимость"? Тестирование приватных методов не имеет смысла, согласен. Нужно строить свой код так, чтобы входные параметры попадали на все условия приватных методов. Все будет ок, больше DI, инверсий зависимости, разнесения на слои и прочее.
Да, ext4.vhdx файл
Понял, но есть ощущение, что это не сработает с wsl