Владимир Чернышев

Добавлю к ответу Юрий:

Одна из основных вкусняшек Workflow в подобных компонентах/фреймворках/системах - это инверсия контроля над сущностями и прочими моделями. Клиент не изменяет статус сущности через условный сеттер setStatus('approved') с дополнительными сайд-эффектами, а осуществляет переход (действие, процесс) apply('approve'), одним из сайд-эффектов которого является изменение статуса. Вроде бы разница незначительная с технической точки зрения, но бизнес-заказчики обычно оперируют процессами, в которых задействованы сущности, а не операциями самих сущностей, они говорят "в результате подписания договора ему присваивается статус "действующий"", а не "присвоение договору статуса "действующий" означает что договор подписан". Когда их требование меняется на "в результате подписания договора ему присваивается статус "подписан" (которого раньше не было), а "действующий" присваивается когда менеджер его утвердит", то нам, разработчикам, значительно меньше приходится менять и чаще всего не код даже, а конфиги, код только дописывается, но не меняется, ну или меняется значительно в меньшей степени.

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

Сервисы использую когда в методах различных сущностей появляется дублирование кода или просто непонятно к какой сущности отнести тот или иной метод — типичный пример: перевод со счёта на счёт, оба счёта в принципе равноправны, и что метод DebetTo в источнике, что метод CreditFrom в получателе будет выглядеть некрасиво, особенно если будет ещё и третий счёт, на который перечисляется комиссия за транзакцию, а создание класса транзакции в модели нецелесообразно — прямой кандидат в сервисы. Вообще сервисы рассматриваю как функции.

С Yii плотно не работал, потому просто мнение:

ORM в Symfony (Doctrine2), имхо, мощнее чем в Yii по определенению. DataMapper+UoW vs ActiveRecord. Плюс хранлище на основе SQL СУБД без особых проблем может быть заменено на что-то другое, MongoDB, например, также из коробки почти. Но, вероятно, DM несколько тормознутее AR за счёт широкого использования отражений. Решается путем создания кастомных репозиториев, где хоть напрямую SQL вызывайте, не пользуясь DBAL.

Доступ в sf2 может быть основан на чём угодно, главное реализовать isGranted(). На основе ролей — из коробки.

Вообще модульность и низкая связанность сильная сторона sf2 (не в последнюю очередь из-за DI где нужно и где не нужно :) ). Другие full-stack PHP фреймворки, что поверхностно изучал, этим похвастаться не могут. В sf2 жёсткие связи используются мало, почти всё конфигурируется: не нужны предлагаемые абстракции роутера — напишите свой класс хоть на switch case, хоть на C, главное нужный интерфейс реализуйте и строчку в конфиге поправьте (а можно и не править, но, имхо, не стоит).

Его ненужностью для каждой разработки?

Почитайте www.symfony-project.org/jobeet/1_4/Doctrine/ru/12 — если я правильно понял (вопрос сформулирован как-то очень сумбурно «создаю доктрину» и т. п. — явно не термины symfony да и вообще не термины :) ), то речь идёт о генерации админки.