Какие архитектурные решения можно применить?

Question

[Арамаис Мирзоян]

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

какие архитектурные и структурные решения можно применить в этом случае. Так же приветствуется аргументированная критика кода. Проект написан на Laravel.

ссылка на репозиторий

Comments

[mayton2019]

"отсутствуют архитектурные и структурные решения для бизнес логики"

Да. Подобного рода отписка - это издевательство. Беря во внимание что никто не в состоянии
формализовать архитектуру и структуру. По крайней мере я не встречал нигде чек-лист
чтоб это можно было как-то проверить.

Видимо вы им просто не нужны. И я-бы не стал сильно переживать по этому поводу.

И как всегда можно подтвердить еще раз мой тезис о том что тестовые задания никто никогда не смотрит.
Потому что если-бы смотрели - то был-бы выдан список code-review points с пожеланиями.

[Арамаис Мирзоян]

mayton2019, я тоже считаю, что это не совсем справедливо. И у меня тоже было такое ощущение, что совсем не смотрели задание. Просто тут был ещё один нюанс, они сказали, что ожидали что я выполню задание за 2 часа, а я честно им сказал, что потратил на выполнение 8-9 часов. Я понимаю, что у всех разная скорость работы, но в моей голове не укладывается, кто бы смог выполнить это задание за 2 часа, при этом делая это хорошо. Чтобы были тесты, документация и хороший код, а не, чтобы все простынью в контролере. И вторая причина отказа был в том, что я якобы потратил больше времени на выполнение и это уже зарплатные ожидание ожидания джуна, а не мидла. По мне бред какой-то, а вы что думаете?

Я особо не переживаю, просто неприятно, что свое время потратил на этих неадекватов.
И зачем они заставляют делать тестовое, если всё равно не смотрят?

[Елена]

Это было требование компании - использовать laravel?

[Арамаис Мирзоян]

Елена, можно было написать на Laravel, Yii или Symfony. Я выбрал Laravel, потому что с ним больше всего опыта.

[Максим]

Арамаис Мирзоян, фреймворк не играет роли в вашем случае. Фреймворк это инфраструктура. А бизнес логика и сервисы пишутся на PHP либо имея минимальные зависимости.

[Арамаис Мирзоян]

Максим, я с вами согласился бы, если бы использовали, например, Slim, только для рутинга. Но раз используем Laravel, должны использовать всю магию Laravel. Есть ли смысл сделать фреймворканезависимую атхитектуру, используя такое тяжелое решение, как Laravel?

По сути из всего прекрасного функционала Laravel будем использовать только руты, но при этом тянуть с собой всю эту обузу, в виде лишнего кода, как я понимаю.

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

[Максим]

Арамаис Мирзоян, небольшое отступление… Slim - это всё же микрофремворк. Laravel и Symfony - компонентный фреймворк. Yii2 - монолитный фреймворк. Например, у Symfony тоже есть возможность использовать его минимально - вот его скелетон.

Теперь ответы на вопросы:

Есть ли смысл сделать фреймворканезависимую атхитектуру, используя такое тяжелое решение, как Laravel?

Есть. Деление на слои это вообще не про фреймворки. Если Вы считаете обратное, тогда почему вам в сущность User сразу не кидать Request. Доставать из него нужные данные и сохранять в базу. Но почему-то так не делают. Потому что нижний слой не должен зависеть от верхнего. Сущность - это Ваша модель бизнеса. Если поместить туда вещи от фреймворка, то тогда это может вводить в заблуждение. Так же это ненужная зависимость. Предположим вы прокинули Request сразу в User. Тогда при любом изменении контракта Request - вам придётся менять это во всех сущностях. Так же Request есть в Web, но нет в Console. Кроме того ваши данные вообще могут быть загружены по API из стороннего сервиса через Guzzle. Тогда фреймворк ваш вообще ни каким боком не упал. Или вы захотите выделить систему Auth в микросервис. Если вы программировали изначально зависимую систему, то вам это будет сделать сложно. К тому же есть и другие проблемы. Вот Yii2 перестал развиваться. Yii3 ещё не вышел. И вы стали ограничены в развитии. Чтобы перейти на новый фреймворк - вам нужно отвязать ваш код от фреймворка, затем перенести на новый фреймворк и уже там накинуть инфраструктуру на ваш код. Описал сумбурно и точечно, но суть должна быть ясна.

По сути из всего прекрасного функционала Laravel будем использовать только руты, но при этом тянуть с собой всю эту обузу, в виде лишнего кода, как я понимаю.

Вам никто не запрещает использовать не только рауты. Сделайте свою обётрку и вам вообще не важно какая там зависимость. Этот же Mailer в проекте будет иметь MailerInterface в качестве контракта и реализацию LaravelMailer, SymfonyMailer, UnisenderMailer и так далее.

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

Если проект будет жить больше года и в нём не пару строк кода, то лучше сразу применять. Она вообще не громоздкая. Вам так кажется. Вам будет проще жить с этим. Будет меньше ошибок. Представьте контроллер на 15 строк кода или на 1500. Тут вам решать. Жёсткая необходимость заключается в развитии. Если оно есть - это уже ваш критерий. Единственное вам может казаться что она громоздкая только потому что вы плохо в ней ориентируетесь и мало что знаете про это. По таким суждениям тогда и не нужны лишние библиотеки, вроде Psalm, PHPUnit, Rector, Deptrac, PHP CS Fixer и так далее. Зачем вообще себя утруждать писать лишний код в тестах, какую-то типизацию делать в проекте)) Слишком громоздко… И так сойдёт.

[Арамаис Мирзоян]

Максим, спасибо, я вас понял

Если проект будет жить больше года

Вот не всегда поймешь это сразу

Зачем вообще себя утруждать писать лишний код в тестах

Ну по мне тесты, это жесткая необходимость в современном мире. А вот про применение DDD, пока что точно не могу утверждать аналогичное, скорее, по ситуации. Потому что многие и без него нормально живут.

И когда тебе кидают задание, ты должен реализовать по дефолту по архитектурному решению, как они ожидают или в любом случае пожелания должны указывать в ТЗ, как вы думаете?

И если отправите пару ссылок с более подробными объяснениями того, о чем вы говорили, будут очень благодарен.

[Максим]

Арамаис Мирзоян, учитесь понимать) Либо не работайте с такими проектами. Тут уже выбор ваш. Я лишь поделился мнением.

Если вы пишите тесты, то наверняка сталкивались с проблемой написания тестов для сущности. Вместо того чтобы написать простой и быстрый Unit Test вам приходиться писать функциональный тест с Фикстурами. Из-за чего ваши тесты выполняются на много дольше. При больших обьемах это могут быть и часы. Вот вам и причина почему сущность не должна ничего знать про место хранения. Вот вам и «громоздкая архитектура». А получилось громоздкое тестирование. Так что не думайте что упростили свой код и проект таким образом. Жить можно и без DDD можно и на лошадях ездить. Ваша задача применять эти знания. Вам вряд ли придет в голову ехать за 1000 км на лошадях. Вот и тут не нужно говорить о том что это громоздко. Применяя DDD вы код читаете как книгу и если вы вернетесь к проекту через год - вы легко в него погрузитесь и внесете нужную правку. А вот без него вы будете часами искать и дебажить.

[Максим]

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

Да ссылок тут не напасешься. Из много. Про ддд думаю и сами найдете. Теория есть вся в интернете. Хабр в помощь. А вот практика дело другое. Могу поделиться своим открытым шаблоном для проектов на Symfony https://github.com/Myks92/project-feature-skeleton

Ну или если что пишите в телеграм. По возможности отвечу

[Арамаис Мирзоян]

Максим, в ваших словах есть логика

[Арамаис Мирзоян]

Максим, я немного другое имел в виду, если, например, компания отправляет тестовое задание для принятия на работу, а потом в причинах отказа указывает "отсутствуют архитектурные и структурные решения для бизнес логики" и никак не раскрывает подробности. Это получается по дефолту все тестовые задания нужно реализовать с применением DDD или каких-то слоев взятых из него, если даже о необходимости применения такого подхода не указанно изначально в таске, как вы считаете?

И если вы ему предложите выбор по лайту и без ддд, то он быберет что дешевле и проще

А если предложишь с DDD вариант сразу, тогда уже предвижу возражения дорого/долго) Хотя от типа заказчика тоже зависит.

Спасибо за помощь! Изучу вопрос.

[Максим]

Арамаис Мирзоян, по компаниям сложно сказать. Каждая компания преследует свои цели. Какая-то может вообще не дать обратную связь, а какая-то возьмет вас и будет обучать пробелам в знаниях. Прежде чем делать тестовое задание нужно знать цели этого задания и критерии. Кроме того вам могут дать отпуску, а по факту просто нашли уже человека. Я к тестовым заданиям отношусь с осторожностью. Если их оплачивают, то могу рассмотреть, а если нет - я предпочту пропустить. Для того чтобы понять мой уровень достаточно посмотреть открытый код.

Заказчик всегда ищет вариант проще. Я даже встречал таких, кому экономили 3млн за разработку продукта, а они, вместо того чтобы пустить на поддержку и развития продукта просто куда-то проели. Так что сэкономив компании 3млн заказчик всё равно скажет, что у него нет денег на ваши хотелки. Тут работа с клиентами и ценностью.

Answer 1

[Максим]

1. Нет деления по слоям из DDD. Нужно отделять бизнес логику от инфраструктуры. Ответственно контроллерах минимум кода и никакой логики.
2. Анемичные сущности, которые не имеют контроля над своим состоянием агрегата.
3. Сущности знают про то где они хранятся. Если завтра мы начнем хранить данные в другом месте, то ваш код придётся переписывать.
4. Про структурные паттерны можете почитать тут: https://refactoring.guru/ru/design-patterns/struct.... Там есть примеры на PHP.

В целом могу сказать, что код пишется для человека, а не для машины. Поэтому не нужно бездумно писать код и раскидывать всё в разные папки по всему проекту. Выделяйте модули и ложите всё рядом с ним. Можете почитать про модульный монолит.

Например, у вас Request размазан по разным папкам: Events, Models, Listeners и т д. Вам завтра скажут вынести модуль заявок в отдельный сервис или вообще его удалить. Вместо того чтобы удалить одну папку, то вам нужно во всех папках найти где есть Request. Конечно, это не удобно. Не говоря о том, то вся логика, в том числе и бизнес логика хранится по всему проекту. И это у вас простой код. А что если будет 100 разных модулей. С вашей структурой вы точно увязните. Плюс у вас будет куча конфликтов при разработке. Нельзя за каждым программистом закрепить папку, за которую он отвечает. Каждому программисту придётся лезть в соседнюю попку, потому что они общие. Ревью делать тоже сложно.

Comments

[Елена]

Сущности знают про то где они хранятся. Если завтра мы начнем хранить данные в другом месте, то ваш код придётся переписывать.

- насколько я понимаю это концепция active record, которая используется в ORM в laravel, как таковых сущностей там нет. Как можно это исправить, учитывая что от этой ORM по умолчанию не отказываться? Вводить сущности по аналогии symfony и городить адаптеры?

[Максим]

Елена, всё верно. Active Record тем и плох, что это не контролируемо. Тоже самое у Yii. Вы можете в любом месте вызвать публичное поле $user->status = 'active' и пользователь стент активирован. И разработчику плевать о том, какую логину переходов из статуса в статус вы заложили. Например, для User вы можете поставить условие, что пользователя можно активировать только в том случае, если его почта подтверждена. Для этого в методе activate() вы добавляете проверку подтверждения. Если не подтвердил - выбрасываем исключение. Таким образом ваша система и сущность User всегда соблюдает бизнес требования. Вы защищены от вмешательств через публичные поля. Кроме того в этом же методе activate() можно опубликовать событие для другого модуля, который пришлет приветственное письмо с дальнейшими инструкциями. Если изменять статус напрямую ничего этого не будет.

Да, я вижу ваш акцент на то, что придётся городить дополнительные аннотации, писать правильные методы и отделять хранилище репозиторием. Но я ещё ни разу не видел проблем от этого. Проблемы бывают с Active Record. Он полезен только на старте, а дальше он дает кучу проблем. Если ваш проект надолго, а не какой-то стартап, то писать лучше не с антипатерном Active Record. Вы всё равно придёте к этому. Вопрос только времени.

Answer 2

[Василий Банников]

У тебя сейчас вся логика в контроллерах написана.
Видимо, оценивающий хотел увидеть разделение.

А вообще подобные вопросы надо задавать тому, кто оставил замечание

Comments

[Арамаис Мирзоян]

Не получилось выйти на связь напрямую с ним. Минус в том, что не дали нормальную обратную связь. А какие решения вы бы предлагали? Вывести всё это в сервисы или в модель? Или применить какой-нибудь паттерн?

[Василий Банников]

Арамаис Мирзоян, я не пыхер, так что хз как у вас это принято называть.
Вообще да - какой-то сервис, который действует в терминах твоей предметной области, а не в терминах http запросов и ответов

Answer 3

[Елена]

Арамаис Мирзоян посмотрите в эту сторону https://github.com/faisalarbain/decouple-entitiy-f..., тут дан пример реализации паттерна репозиторий на примере ларавеля

Comments

[Арамаис Мирзоян]

Ну про репозиторий двоякое мнение, многие не рекомендуют использовать этот паттерн.