А куда сеттеры нужно убрать?

Для начала давайте различать сеттеры, которые сгенерированы вашей IDE или симфоневским генератором, и сеттеры которые реально нужны.

Вот вам простой пример. У вас есть требование "пользователь должен иметь возможность сменить пароль" и у вас появляется метод:

function changePassword(string $password, callable $hasher) : void 
{
     $this->password = $hash($password); // мы никогда не забудем захэшировать пароль
}

А если в рамках требований нужно сменить сразу 4 свойства — мы либо делаем метод с 4-мя аргументами, либо, что вероятнее, уберем эти 4 свойства в отдельный объект-значение (гуглить doctrine embeddable), и будем просто заменять оный.

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

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

В большинстве случае entity доктрины генерируются из бд через консоль автоматически

Вот честно за 5 лет ни разу так не делал. Более того, разработчики доктрины не рекомендуют так делать.

Использование доктрины подразумевает что схема базы данных генерируется из сущностей, а не наоборот (хотя так и можно просто сложно и теряется профит). То есть мы сначала проектируем сущности (бизнес-объекты) со своей бизнес логикой, моделируем предметную область а уже потом занимаемся второстепенными вещами вроде "схему базы генерим".

То есть если мы работаем с доктриной и представляем сущности как тупую проэкцию рядов таблиц на объекты — вам не нужна доктрина. Вам хватит какого-нибудь active record.

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

Потому что у вас в сущностях сеттеры, а не потому что это просто лучше) Есть такой шаблон проектирования (или скорее даже принцип) под названием "информационный эксперт": информация должна обрабатываться там, где она есть. То есть в нашем случае пока бизнес логика находится в рамках одной сущности или мы можем легко выделить корень агрегата сущностей — лучше эту логику пихать в сущность. А уж если мы не можем выделить корень агрегата (например надо посчитать сумму всех заказов пользователя и сущность пользователя ничего не знает о заказах) то тогда да, выносим это дело в сервис. Но подсчет суммы одного заказа — дело самого заказа.

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

тут нет никакого спора. Когда у вас больше действий в контроллере, у вас нет разделения бизнес логики и презентационной логики, и называется это SmartUI. Вполне себе годный вариант для CRUD-а например, и покрывает он подалвяющее большинство проектов. Это не плохо, просто на более сложных проектах с более сложной логикой вы проиграете. В лучшем случае все закончится нарушением DRY. В худшем — связанность системы будет настолько высока, что сопровождать проект будет болью (как для разработчика, так и для бизнеса)

Вы можете выполнять действия в классе Entity или можете вынести эти функции в модель или репозиторий

Просто приведите формулировку термина "модель". Что это у вас? Модель предметной области? Какая-то другая модель?

Здесь скорее вопрос кому как нравится.

Ну да, и принципы всякие вроде SOLID или GRASP придумали от скуки.

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

Геттеры придумали в java что бы иметь возможность получать состояние. С ними все хорошо поскольку они не мутируют состояние объектов.

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

Не важно нужны они вам или нет, это не значит что их, относительно данной статьи, не должно быть у других, и что это не правильный подход.

Культ карго. Люди будут делать так как показали вне зависимости от размеров проекта. Без какого либо понимания что они делают и зачем.

А на счет модели я думал вы знает для чего их придумали.

Понимаете ли, это не имеет значения. Меня интересует ваша интерпритация что бы мы говорили на одном языке. Ибо для меня модель — это модель. А сущность — представляет собой модель бизнес объекта, одного. Сервис представляет модель взаимодействия нескольких несвязанных между собой сущностей (ибо если они связаны они сами разберутся).

В doctrine просто работу с данными можно вынести в repository, а так в модели.

Репозитории это вещи, которые отвечают за хранение. В них может находиться бизнес ограничения вроде "можем ли мы ложить туда эту сущность или нет". Но репозитории НЕ мутируют состояние сущностей. Это просто склад. Склад который меняет состояние объектов там хранящихся — плохой склад.

$blog = Blog::fromArray([
    'title' => 'A day in paradise - A day with Symfony2',
    'description' => 'Lorem ipsum dolor sit d us imperdiet justo scelerisque. Nulla consectetur...',
    'image' => FileReference::local('beach.jpg'),
    'tags' => $this->tags(['symfony', 'php', 'paradise', 'symblog']) // получить референсы на тэги например,
]);

$blogRepository->add($blog); // никаких entity manager-ов.

Вообще удивительно что в вашем примере вы не сами вызываете setId. Ну и в целом фикстуры отстой, фабрики фикстур рулят.

если (нужна_работа И есть_навыки) {
    иди_в _1С
}

listen                      443 ssl spdy;
ssl                         on;
ssl_protocols               TLSv1.2 TLSv1.1 TLSv1;
ssl_session_cache           shared:SSL:20m;
ssl_session_timeout         10m;
ssl_ciphers                 'EECDH+ECDSA+AESGCM:AES128+EECDH:AES128+EDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!ADH';
ssl_prefer_server_ciphers   on;

resolver                    8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout            10s;
add_header                  X-Frame-Options             "DENY";
add_header                  X-Content-Type-Options      "nosniff";
add_header                  Strict-Transport-Security   "max-age=31536000";
add_header                  Public-Key-Pins 'pin-sha256="[SOME_BASE64]"; max-age=5184000;';  #[SOME_BASE64] надо выставлять свое, гуглить как считать Public-Key-Pins
ssl_stapling            on;
ssl_trusted_certificate /etc/nginx/ssl/[SITE]/trustchain.pem;
ssl_certificate         /etc/nginx/ssl/[SITE]/server.crt;
ssl_certificate_key     /etc/nginx/ssl/[SITE]/server.key;
ssl_dhparam             /etc/nginx/ssl/[SITE]/dh.pem;        #openssl dhparam 2048 -out dh.pem