Symfony *

Проектирование своего проекта по DDD последнее время становится всё более популярным. Сейчас не будем углубляться в данную методологию с её принципами, плюсами и минусами. Я хочу рассказать с какой проблемой столкнулась наша команда при использовании данной методологии на PHP, а именно внедрении Data Mapper’а Doctrine ORM.

Чтобы более понятно донести нашу проблему я буду использовать известный всем Агрегат Заказа (Order) и позиции заказа (OrderLine), которые являются коллекциями Dortrine ORM. Так же сильно упростим данный агрегат, чтобы фокусироваться на самой проблеме. И так начинаем!

Для начала мы создадим наш агрегат заказа.

Рано или поздно, каждый пэхапешник, пишущий на битриксе, начинает задумываться о том, как бы его улучшить, чтобы и всякие стандарты можно было соблюдать, и современные инструменты разработки использовать, да и костылей чтобы поменьше было, хотя без последних, конечно, совсем никак не получается.

И вот в один прекрасный момент, попробовав Blade и Twig, я задумался о том, как бы какой-нибудь шаблонизатор к битре прикрутить.

К счастью, в подобных мыслях я был не одинок, и рунет выдал несколько результатов по подключению шаблонизаторов, в том числе, и в официальной документации. Однако ни одно решение меня не устроило по тем или иным причинам - что-то уже не поддерживается, где-то кодировка не та, где-то код уже устарел.

В итоге, перелопатив (почти) всю информацию по этому поводу, я решил создать своё решение (почему никто не удивлён?). Сначала была идея запилить модуль, но потом решил использовать composer-пакет.

Это было небольшое вступление, теперь непосредственно к сути.

Как известно, с ростом размера кода приложения его становится все сложнее и сложнее поддерживать. Рассмотрим подход, как с наименьшими усилиями структурировать код Symfony приложения так, чтобы снизить затраты на внесение в него изменений и упростить переиспользование или замену его частей. По каким принципам разбивать функционал на модули, как обобщать, как называть, разберем на примере. У нас будет цельное приложение, но если понадобится, выделить нужный компонент мы сможем с минимальными усилиями.

Подборка свежих новостей и материалов из мира PHP. Вышла третья бета PHP 8.1, Swiftmailer больше не будет поддерживаться, PHP-FIG обсуждает обновляемые стандарты PER. Для PHP 8.2 предложены два новых RFC: про удаление динамических свойств и перегрузку операторов. Также в выпуске порция полезных инструментов, статьи и видео.

Приятного чтения!

Без году неделя как я одним пятничным утром провел инсайд доклад для группы разработки в компании. Речь шла о довольно занимательном командном опыте ремастера проекта через применение множеств, в наше время, уже не новых практик и подходов, но ранее мне неизвестных.

После применения ряда рецептов я сравнил показатели производительности двух версий системы легаси и ремастера и был, мягко скажем, приятно удивлен. Такие подходы, как отделение слоя интерфейса от монолита, SPA и технологии прогрессивного рендеринга заставили меня взглянуть на разработку веб-продуктов совершенно иначе.

Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".

Эта статья аккумулирует в себе те практики, которые мне близки и которых я придерживаюсь в разработке.

Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP ​, которые могут чуть подробнее раскрыть то или иное понятие.

Начнем мы сразу с доменного слоя нашего приложения, то есть с бизнес логики нашего приложения.

Когда-то вы кодили на одном большом и могучем серваке, с кучей памяти и кучей процов. Сервер был безграничен, все ваши сервисы были здесь, все ваши Redis’ы и даже зачастую MySQL-и были тут. Все ваши приложения были здесь же: какая-то аналитика, какой-то бэкенд для админки, еще десяток сервисов — все было рядом. 

Но вот вы заехали в Swarm. Все приложения — это набор контейнеров. А контейнеры это, по сути, набор микросерверов со своей файловой системой, своей памятью, своими процами. И они уже не всегда рядом. Соответственно, это тянет за собой некоторые изменения. 

В компании Outsourcify мы работаем над проектами разного размера: от небольших сайтов, состоящих из нескольких страниц, до сложных бизнес-приложений. В зависимости от конкретного случая мы рекомендуем клиентам разные технические решения (например, мы пишем много одностраничных приложений на JavaScript и работаем с WordPress), но в самых сложных сценариях, когда разрабатываются крупные веб-приложения, занимающие группу разработчиков на несколько недель или месяцев, мы отдаем предпочтение фреймворку Symfony.