если говорим про таблицы то я бы сделал просто SQL запрос, никаких сущностей тут не надо.

Если мы говорим про бизнес логику то я бы больше внимания уделял вопросам "а что если цена поменяется а еще не оплатил" (в некоторых странах такое поведение системы будет считаться мошенничеством). Ну или что будет происходить с уже заказанными товарами когда ты захочешь стоимость поменять.

Возможно тут и найдешь ответ на свой вопрос.

Проектирование - область знаний и деятельность, архитектура - результат (один из) проектирования.

Доброго вечера, чат. Я тут набрёл на последнюю статью в блоге дядюшки Боба и к своему стыду не понял, в чём профит для той ситуации, которая описана в самом начале.
Я бы пересказал, но боюсь, что не донесу суть, а разолью её по дороге. Буду благодарен, если у кого-то найдётся время прочитать и объяснить простым языком.
Прилагаю ссылку: https://blog.cleancoder.com/uncle-bob/2021/03/06/ifElseSwitch.html

Это о классической замене if-а или switch-а полиморфизмом.

Профит будет только если эти проверки на gender повторяются во многих местах.

Стоит все ж обратить внимание что для кейса из твита сам боб ничего плохого в варианте со switch (а в пыхе уже есть match для такого) нету.

Имеет смысл смотреть на стабильность модуля. Если эта штука часто меняется или просто правила сложнее (у меня вот есть под рукой кусок Легаси с 30-ю ветками и внутри ещё всякие разные преобразования) то с целью увеличить стабильность отдельных частей или просто для снижения сложности можно использовать такой подход.

Все ж куда безопаснее работать с системой где каждый кусочек можно представить копией и заменить ею старый нежели постоянно менять нутро модулей.

Здравствуйте, уважаемые знатоки.

Подскажите пожалуйста по поводу разбиения приложения по вертикальным слоям. Вот, есть у нас разные "фичи" (не подберу русского эквивалента) приложения, и они определяют вертикальные слои.
Каждый вертикальный слой может иметь необходимое разбиение на горизонтальные (домен, приложение, инфраструктура), но иногда "фича" не требует отдельных доменных объектов, например CRUD, и его можно обработать прямо в слое приложения (в обработчике для соответствующей команды) используя ORM/Qeury builder.

Правильно ли все это, и если да, то нужно ли нам иметь отдельные "фичи" типа "CreateUser", "DeleteUser" и т.п.? Или же можно обозвать это прямо "UserCrud", или же вообще не нужно тут городить команды/обработчики а весь CRUD сделать прямо в контроллере фреймворка? Название "фич" я хотел бы использовать для структурирования файлов команд/хэндлеров/классов для доменных объектов. По идее архитектура это не что-то догматическое, но тогда скажите пожалуйста, как вы делаете это в своих проектах.

Заранее спасибо!

Мне кажется правильнее создавать use cases в слое приложения по типу: создать пользователя, удалить пользователя. Они определяют сценарии взаимодействия с системой. Внутри происходит взаимодействие с инфраструктурой и доменом.

Видел это? 😂
куча вложенностей в phtml)))

ну вот у меня есть такое

как понять является ли это проблемой - глянуть историю изменений файла: https://github.com/laurentlepee/magento-ce-1.9.2.4/commits/master/app/design/frontend/base/default/template/catalog/product/price.phtml

если изменений не много - не болит

Могу инсандерскую инфу предоставить - просто все боялись лезть в этот файл. Это не значит, что проблем не было ;)
Я 3 года в Мадженто (команда разработчиков ядра фреймворка) работал

какие ж трусливые... не самое страшное что я видел в жизни

да вьюшка как вьюшка

далеко не самое и такое легко достаточно рефакторить

а главное можно продебажить) в отличие от всех этих шаблонизаторов. с ними бубен нужен

вообще лапша и полотна это не страшно, это сложно менять и разбираться но зачем брать на себя такие риски - копируешь, меняешь, тестишь, сравниваешь работу, готово - заменяешь

вот где страшно - это всякие бесконечные цепочки вызовов между файлами с неявными зависимости от того че когда вызвали и общим стэйтом. Вот там сорян. Там нужно понимать как это все в рантайме работает или в целом заниматься сбором требований на основе решения и делать с нуля (по кускам)

ифы их там пугают, нежные какие

там каждый иф - это конфиг. А комбинация конфигов - это умножение. Получается N^M вариаций тестить...
Не забывай - это ядро фреймворка, а не конкретное приложение (вебсайт)