Ни разу не видел удачных реализаций ричмоделей. И первые примеры вызывают сомнения:
Раскидывать свойства энтити по трейтам, кмк, усложняет проект, а не упрощает, нет единого представления сущности. + Есть красивые пакеты для created_at и updated_at.
С транзакциями пример совсем плохой - баланс хранить как итог вместо суммы транзакций плохая практика. Да, можно кэшировать промежуточный итог, но тут явно имелось в виду не это - валидация нужна при фиксации транзакции, а не при кэшировании текущего баланса.
Сразу менее надёжно, т.к. сервис хранения логов может быть где-то на другом сервере. Сетевые издержки, выше вероятность, что что-то может отломаться. А логи часто нужны именно когда что-то ломается.
Плюс вы жёстко завязываетесь в коде на конкретную хранилку.
Лучше всего из приложения логи кидать в самый быстрый и надёжный приемник. Кинули и забыли. А уже внешняя обвязка разберется, что с ними делать.
И я бы не в файл кидал логи, как автор, т.к. это тоже лишняя жёсткая привязка, особенность приложения, о котором все почему-то должны знать. Я бы кидал логи в stderr или stdout. И докеры, и кубы с этим форматом из коробки работают и, собственно, ожидают от вашего приложения логи именно там. И у них даже уже есть драйвера, которые позволяют эти логи маршрутизировать далее, например, драйвер с fluentd (аналог filebeat).
Если на вас или чистом железе разворачивание - такая же история. Плюёте логи в стандартный поток, а уже тот, кто разворачивает/запускает ваше приложение, решает, куда он его (поток логов) направит.
Если делаете пета и не очень в девопс, то можно и в файл писать. Если это коммерческая разработка, над которой работают много людей и приложение разворачивается в множестве различных окружений, да ещё и не одно (например, микросервисы), то совершенно точно не стоит писать в файл, а тем более через сеть в конкретную бд.
А как же symfony? Отличный фреймворк, современны, мощный, насыщен современными лучшими подходами в вебе. А-ля спринг на пхп. Кроме него есть ещё несколько хороших фреймворков, которые отлично подходят для Энтерпрайза. Конечно же, есть свои нюансы, в целом, лучше, имхо, выбрать джаву или го. Но на пхп можно собрать не менее устойчивое и надёжное приложение. А в определённых ситуациях, даже, будут свои преимущества перед другими стеками.
Вместо кучи чувствительных данных переменного размера надо таскать только один ключ. Ответственность за эти данные перемещается от девопса к программисту. В некоторых ситуациях очень удобно такой штукой пользоваться.
Это точно переводить не надо ) Но очень странно, если человек способен прочитать банду в оригинале, а перевод такого простого слова не знает )
Ни разу не видел удачных реализаций ричмоделей. И первые примеры вызывают сомнения:
Раскидывать свойства энтити по трейтам, кмк, усложняет проект, а не упрощает, нет единого представления сущности. + Есть красивые пакеты для created_at и updated_at.
С транзакциями пример совсем плохой - баланс хранить как итог вместо суммы транзакций плохая практика. Да, можно кэшировать промежуточный итог, но тут явно имелось в виду не это - валидация нужна при фиксации транзакции, а не при кэшировании текущего баланса.
Переводится именно так. Непонятно, как за "21 год разработки" можно было "это" услышать впервые.
Так написали с Касперским и приведена ссылка на разбор, как это работает.
Сразу менее надёжно, т.к. сервис хранения логов может быть где-то на другом сервере. Сетевые издержки, выше вероятность, что что-то может отломаться. А логи часто нужны именно когда что-то ломается.
Плюс вы жёстко завязываетесь в коде на конкретную хранилку.
Лучше всего из приложения логи кидать в самый быстрый и надёжный приемник. Кинули и забыли. А уже внешняя обвязка разберется, что с ними делать.
И я бы не в файл кидал логи, как автор, т.к. это тоже лишняя жёсткая привязка, особенность приложения, о котором все почему-то должны знать. Я бы кидал логи в stderr или stdout. И докеры, и кубы с этим форматом из коробки работают и, собственно, ожидают от вашего приложения логи именно там. И у них даже уже есть драйвера, которые позволяют эти логи маршрутизировать далее, например, драйвер с fluentd (аналог filebeat).
Если на вас или чистом железе разворачивание - такая же история. Плюёте логи в стандартный поток, а уже тот, кто разворачивает/запускает ваше приложение, решает, куда он его (поток логов) направит.
Если делаете пета и не очень в девопс, то можно и в файл писать. Если это коммерческая разработка, над которой работают много людей и приложение разворачивается в множестве различных окружений, да ещё и не одно (например, микросервисы), то совершенно точно не стоит писать в файл, а тем более через сеть в конкретную бд.
А как же symfony? Отличный фреймворк, современны, мощный, насыщен современными лучшими подходами в вебе. А-ля спринг на пхп. Кроме него есть ещё несколько хороших фреймворков, которые отлично подходят для Энтерпрайза. Конечно же, есть свои нюансы, в целом, лучше, имхо, выбрать джаву или го. Но на пхп можно собрать не менее устойчивое и надёжное приложение. А в определённых ситуациях, даже, будут свои преимущества перед другими стеками.
Вместо кучи чувствительных данных переменного размера надо таскать только один ключ. Ответственность за эти данные перемещается от девопса к программисту. В некоторых ситуациях очень удобно такой штукой пользоваться.