Laravel Выбор Framework

[fixxxer]

Я бы хотел как-нибудь послушать @fixxxer о его видении DDD, о подходахи инструментарии, уверен, оно сильно отличается от утопичных теорий еванса и ко.

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

Вкратце подход такой, главное - изолировать слой domain model и на его уровне красиво, на уровне application/infrastructure не выпендриваюсь и KISS/YAGNI.

 

[Вурдалак]

И вся это церковь строится на кривулине имени Doctrine.

Самое смешное, что ни я, ни @fixxxer не используем Doctrine, а ты продолжаешь вырисовывать мысленный портрет «врага», смакуя какие-то проблемы конкретных инструментов. Get over it, инструменты важны, но не в них суть.

Для меня в первую очередь важно иметь rich domain model, и разделение слоёв на уровне неймспейсов (domain, application, ui, infrastructure), а дальше уже можно искать компромиссы.

 

[fixxxer]

Я вот тоже кстати не понял, причем тут Doctrine. Да хоть через mysql_query(), какая разница

 

[grigori]

Get over it, инструменты важны, но не в них суть.
Для меня в первую очередь важно иметь rich domain model, и разделение слоёв на уровне неймспейсов (domain, application, ui, infrastructure), а дальше уже можно искать компромиссы.

да-да, это отлично реализуется на Active Record

 

[fixxxer]

Если модели напрямую мапятся на таблички в базе и все укладывается в банальный CRUD по табличкам - да, можно просто в инфраструктуре держать репозитории, дергать AR-методы только оттуда и все будет вменяемо.

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

Все эти проблемы можно сгладить и с AR, я с этим долго жил и в принципе все решаемо. Но с DM жизнь намного проще.

 

[grigori]

если серьезно, вопрос: в чем отличие "дернуть AR напрямую" от mysql_query("delete from table") напрямую?

 

[Adelf]

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

 

[Вурдалак]

да-да, это отлично реализуется на Active Record

Нет. ActiveRecord — это диаметрально противоположный подход к решению проблемы. Если ты хочешь DDD, то перечеркни все преимущества AR, тогда язык не повернётся сказать, что это «отлично реализуется». Это как сказать, что «да и на моём компе эта игра будет летать, только нужно оперативки раза в 4 больше, процессор новый, видеокарту заменить и SSD поставить». Только это будет уже другой комп.

если серьезно, вопрос: в чем отличие "дернуть AR напрямую" от mysql_query("delete from table") напрямую?

Когда @fixxxer говорил про mysql_query, он имел в виду инфраструктуру. Ты-то говоришь про модель.

 

[stalxed]

Самое смешное, что ни я, ни @fixxxer не используем Doctrine,

Я как-то делал в domain области интерфейс репозитория, а в инфраструктурной реализовывал его на PDO. Я это делал так как необходима была скорость, а модель очень простая. Но что черт возьми, что делать, если модель средняя или сложная? Без Data Mapper до свидания DDD. Писать свой что ли? Это не серьёзно. Только doctrine 2.

 

[fixxxer]

Я как-то делал в domain области интерфейс репозитория, а в инфраструктурной реализовывал его на PDO. Я это делал так как необходима была скорость, а модель очень простая. Но что черт возьми, что делать, если модель средняя или сложная? Без Data Mapper до свидания DDD. Писать свой что ли? Это не серьёзно. Только doctrine 2.

Я лично ничего против Doctrine не имею

 

[stalxed]

Я лично ничего против Doctrine не имею

Я тоже. Просто жаль что нет конкуренции у неё... А у нас выбора.

 

[Вурдалак]

Я как-то делал в domain области интерфейс репозитория, а в инфраструктурной реализовывал его на PDO. Я это делал так как необходима была скорость, а модель очень простая. Но что черт возьми, что делать, если модель средняя или сложная? Без Data Mapper до свидания DDD. Писать свой что ли? Это не серьёзно. Только doctrine 2.

Я тоже ничего против Doctrine не имею. Просто в legacy-проектах, которым по 10 лет, и где уже есть своя реализация DBAL, DM, etc. просто так взять и заюзать Doctrine не получится.

Кстати, если модель реально сложная, то и Doctrine может не помочь: https://github.com/doctrine/doctrine2/pull/1275

Then write a custom mapper: doctrine is not a flexible data mapper, it is a data mapper with a very opinionated approach.

 

[Вурдалак]

Ещё 5 копеек вставлю: мне нравится CQRS-подход, когда по возможности (а это почти всегда) происходит деление на write-only сервисы и read-only (aka query services). В первых — ORM, отсутствие кеша, транзакционная целостность, все дела. Во вторых — низкоуровневые сложные запросы, запросы для статистики, кеш, read-only соединения, никаких сущностей, обычные DTO. Такое деление позволяет иметь преимущества ORM и не страдать из-за того, что «ОРМ — ГОВНО, ПОТОМУ ЧТО МЕДЛЕННО».

 

[grigori]

Yes, получилось

 

[stalxed]

@Вурдалак, у меня складывается ощущение, что CQRS имеет исключительно академическую ценность.
На примерах в статьях он имеет вау эффект, но я не представляю как построить на нём всю систему.
Например регистрация пользователя, write запрос. Дальше нужно пользователя направить на его личную страницу. Это уже read. Но в этой теории write ничего не должен отдавать. А как мне опознать сгенерированный id пользователя? Необходим как минимум он, чтобы перенаправить пользователя на личную страницу.
Т.е. клиент ждёт от большинства write запросов всё равно ответ.

 

[grigori]

@stalxed, get_inserted_id - это классический случай нарушения принципа "изменения не возвращают, выборки не изменяют",
это как-бы документированное исключение

 

[Вурдалак]

@Вурдалак, у меня складывается ощущение, что CQRS имеет исключительно академическую ценность.
На примерах в статьях он имеет вау эффект, но я не представляю как построить на нём всю систему.
Например регистрация пользователя, write запрос. Дальше нужно пользователя направить на его личную страницу. Это уже read. Но в этой теории write ничего не должен отдавать. А как мне опознать сгенерированный id пользователя? Необходим как минимум он, чтобы перенаправить пользователя на личную страницу.
Т.е. клиент ждёт от большинства write запросов всё равно ответ.

Генерируй id до регистрации, откажись от AUTO_INCREMENT. nextval(), например (Postgres, Oracle, любая-нормальная-СУБД). В MySQL можно эмулировать. Я лично стараюсь не юзать AUTO_INCREMENT, избавляет от многих проблем.

 

[fixxxer]

CQRS имеет исключительно академическую ценность.

Ага.

Они его, правда, кривовато переизобрели (и совершенно по-идиотски противопоставляют MVC, под которым, похоже, понимают что-то вроде RoR + AR =))), но в принципе-то то же самое.

 

[fixxxer]

Генерируй id до регистрации, откажись от AUTO_INCREMENT. nextval(), например.

Или вообще UUID

 

[Вурдалак]

Или вообще UUID

Меня смущает, что на практике скорее всего придётся использовать и числовой (для FK, для производительности, для human readablity, etc.) и UUID одновременно.