И да автор, вы настолько не опытны, что даже не поняли почему класс Order не будет работать в доктрине. Для вас специально дополню: doctrine2 построит запрос не экранируя order -> тем самым вы будете получать постоянную ошибку в SQL.
Поэтому к нему важны аннотации. А вот к Project можно опустить аннотации.

Вам сударь пример.

<?php

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;
/**
 * Class Order
 * @package App\Entity
 * @ORM\Entity
 */
class UserOrder
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    private $id;
    /**
     * @ORM\Column(type="string", length=255)
     */
    private $name;

    /**
     * Order constructor.
     *
     * @param $name
     */
    public function __construct(string $name)
    {
        $this->name = $name;
    }

    /**
     * @return integer
     */
    public function getId(): int
    {
        return $this->id;
    }

    /**
     * @return string
     */
    public function getName(): string
    {
        return $this->name;
    }

}

просто акцессоры к свойствам, пускай и дающие какие-то гарантии типа

постыдились бы своих слов.

У вас к Order не указаны аннотации (или любой другой способ задания маппинга), при этом вы используйте его как основной пример, а Project скрывайте, тем самым создаете путаницу.

При этом в Project вы опускайте работу доктрины и ORM паттерна — unitofwork будет следить за полями, и те не заполненные корректно поля вызовут ошибку вставки данных, обновления данных.

То есть конецпция сеттеров и геттеров как раз таки работает на типах, если у вас null вернется в mehod(): string, то вы получайте ошибку, если setter принимает тип, то другой тип вы не сможете туда просетить, сам php уже валидирует за вас данные.
Достаточно написать очень простой тест на объект на set и get и понять что UnitOfWork не будет класть туда null.
То что вы можете где то вызвать setter, а где то его НЕ вызывать, это валидируется внутри схемы через nullable. Мало того, ваше MVC обязано контроллировать входные данные. Ваш запрос должен проходить десериализацию и валидировать еще до того как попадет в слой данных.
Но мы глупые, мы решили опустить MVC, и сразу вводить пользовательские данные в БД.
Но и тут доктрина нас спасает, так как set и get типизированы.
То есть все условия с getter setter выполняются.
Вы же пишите

Тут у нас есть ряд not nullable полей — указаны как явно в аннотации и без указания (по умолчанию false). Вы точно на ревью увидите, что при создании объекта и наполнении его полями — все сеттеры на not nullable были вызваны, а тесты содержат все кейсы проверок? :)
Куда лучше бы было, если бы можно было создать объект одним методом — конструктором или именованным конструктором (например статическим методом). В них был бы четко заложены зависимости и инкапсулировано необходимое для создания объекта поведение.

UnitOfWork вам не даст воткнуть not nullable, как и схема в БД если при создании миграции разработчик целенаправлено не изменил схему, оставив ее в маппинге. При этом даже в этой ситуации unitofwork проверит в setter и если там придет null, он заругается.

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

Выше уже рекомендовали видео Marco Pivetta (Doctrine), прошу посмотреть:
youtu.be/WW2qPKukoZY?t=962

Это мой ответный «совет» :) Без обид :)

Посмотрел, и не понял причем тут ваша статья и лучшие практики в доктрине.
Ваша статья по примерам кода также никак не относится не к symfony, ни к doctrine.
У вас в примерах даже нет аннотации к классам сущностей.
Например Order у вас просто PPO, без определения мета информации.
Order класс не будет работать в доктрине.
Название вашей статьи противоречит свойствам языка PHP (публичные геттеры и сеттеры являются неотъемлемой частью сокрытия данных и реализации).

Документация даёт самые простые примеры, чтобы в API библиотеки или фреймворка можно было быстрее въехать

Вы явно не читали документацию.

У основного автора доктрины есть претензии к документации симфони по использованию доктрины.

Как это относится к статье? Вы сами прочитайте что пишите, «претензии к документации», а что в статье??!
Статья и видео — это два разных материала. Мы обсуждаем статью автора.
Тоже самое про статью от Marco, там никакого отношения нет к материалу автора.
Там описываются совершенно другие проблемы.

1. Статья не относится к symfony
2. Статья вводит в заблуждение новичков.
3. Статья «ниочем»

Автору желаю скорейшего просветления и рекомендую к прочтению книги Мэтт Зэнсдтра PHP Объекты и шаблоны, документацию по doctrine2, документацию по symfony 4+.
Без обид.

А как же баннер kfc или всплывающий баннер яндекс браузера наезжающий на новости, с таким полем ввода баннеры будут не видны(((

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

Но использование стандарта iCalendar было одной из основных целей написания этой библиотеки. Он гораздо более гибкий и используется повсеместно для подобных целей.

В статье так не написано. Русский язык тоже гибкий. И crontab тоже. Вашу задачу (много задач в crontab) теперь придется поддерживать, если вдруг надо поменять расписание запуска какого либо скрипта, нужно деплоить код, в который программист вася обязательно нагадит с обратной совместимостью: ), а если проект растет по настоящему, то 1им сервером не обойтись и нужно все это запустить на 3-10 серверах… а еще рестарт крона будет накапливать задержки, вообщем ждите беды и готовьтесь к худшему.
А если не хотите беды и хотите пить кофе, то сделайте демона, и натравите на него супервизор.

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

Работодатель ничего не нарушил.
В приглашении на работу xored сказано: оформление визы 30 дней.
Автор пишет:

на время оформления визы буду оформлен в новосибирский офис.

Далее логическая цепочка рушится.

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

Я боюсь представить как автор читает чужой код.
И почему все в один голос обвиняют xored.
Можно из любого оффера сделать такую историю и подменить понятия.