Геттеры/сеттеры и проблема с инкапсуляцией в Symfony проектах

    Сравнительно недавно работаю с Symfony (чуть более года) и во всех проектах, что довелось поработать — сущности всегда создавались таким образом, что они содержали только приватные поля и голые сеттеры/геттеры к ним.

    В статьи будут рассуждения и примеры, почему такой подход опасный, а именно: нарушает нашу старую добрую инкапсуляцию, провоцирует писать код с багами и повышать сложность системы.
    В статье будет опущена тема сеттеров в разного рода билдерах и тема инъекции зависимостей через сеттеры (скажу только, что не одобряем). Не будет ничего про сложные темы вроде DDD, Rich Model, про coupling/cohesion и другие умные слова — просто поговорим про инкапсуляцию. Добро пожаловать под кат.

    Сразу к коду. Давайте опустим на секунду тайпхинт и указание возврата типа и подумаем, чем при работе с объектом отличается с утилитарной точки зрения такой код:

    $userName = $user->name;
    $user->name = $newUserName;
    
    от кода:
    $userName = $user->getName();
    $user->setName($newUserName);
    

    Опять же, если не учитывать типы, то ничем.

    Cам же объект в таком случае практически ничем не отличается от обычной структуры. То есть по сути такой код провоцирует нас писать процедурный код — процедуры, которые работают с данными и меняют их.

    Инкапсуляция


    Что же такое инкапсуляция? Под инкапсуляцией обычно понимают сокрытие данных, поведения, деталей и условий. Когда мы раскрываем детали, то наш мозг и плохое воспитание сразу толкают нас на использование всего, что доступно тут и сейчас, чтобы выполнить задачу по пути наименьшего сопротивления.

    Давайте попробуем «поломать» простой объект, а именно привести его в невалидное состояние:

    class Order
    {
         private const STATUS_OPEN = 'open';
         private const STATUS_DELIVERED = 'delivered';
    
         private ProductCollection $products;
         private string $deliveryStatus;
         private ?DateTime $deliveryDate = null;
    
         public function deliver()
         {
              if ($this->isDelivered()) {
                   throw new OrderDomainException('Order already delivered.');
              }
    
              $this->deliveryDate = new DateTime();
              $this->deliveryStatus = self::STATUS_DELIVERED;
         }
    
         private function isDelivered(): bool
         {
             return $this->deliveryStatus === self::STATUS_DELIVERED;
         }
    
         // пара геттеров
    }
    

    Есть ли возможность доставить заказ «не так» где-то вне объекта? Например не указать статус или не проставить актуальную дату? Есть ли возможность начать городить логику с условием — отправлен ли заказ или нет? В данном виде нет такой возможности. Это пример инкапсуляции — поведение и данные сокрыты, наружу торчит один лишь метод, который мы разрешаем использовать. Кроме всего прочего у данного кода хорошая внутренняя связанность (cohesion).

    Теперь посмотрите на этот пример:

    class Order
    {
        private const STATUS_OPEN = 'open';
        private const STATUS_DELIVERED = 'delivered';
    
        private ProductCollection $products;
        private string $deliveryStatus;
        private ?DateTime $deliveryDate = null;
    
        public function getDeliveryStatus(): string
        {
            return $this->deliveryStatus;
        }
    
        public function setDeliveryStatus(string $deliveryStatus): void
        {
            $this->deliveryStatus = $deliveryStatus;
        }
    
        public function getDeliveryDate(): ?DateTime
        {
            return $this->deliveryDate;
        }
    
        public function setDeliveryDate(?DateTime $deliveryDate): void
        {
            $this->deliveryDate = $deliveryDate;
        }
    
        public function getProducts(): ProductCollection
        {
            return $this->products;
        }
    
        public function setProducts(ProductCollection $products): void
        {
            $this->products = $products;
        }
    }
    

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

    Сеттеры


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

    Это чревато очень сложным запутанным кодом — кодом, который тяжело дебажить, а логику тяжело понимать, так как сеттинг параметров объекта происходит в неожиданных местах, слоях и с диким условиями, да еще и в отрыве от других данных.

    Ну и такие объекты легко сделать не валидными. Пример доктриновской сущности:

    Код некоторой сущности
    /**
     * @ORM\Entity
     */
    class Project
    {
        /**
         * @var Id
         * @ORM\GeneratedValue()
         * @ORM\Id
         */
        private $id;
        /**
         * @var string
         * @ORM\Column(type="string")
         */
        private $name;
        /**
         * @var string
         * @ORM\Column(type="string", nullable=false)
         */
        private $status;
        /**
         * @var int
         * @ORM\Column(type="integer", nullable=true)
         */
        private $sort;
        /**
         * @var User
         * @ORM\Column(type="user_type", nullable=false)
         */
        private $user;
        /**
         * @var Department
         * @ORM\OneToMany(targetEntity="Department")
         */
        private $department;
        /**
         * @var string
         * @ORM\Column(type="string", nullable=true)
         */
        private $membership;
        
        public function getId(): Id
        {
            return $this->id;
        }
        
        public function getName(): string
        {
            return $this->name;
        }
        
        public function setName(string $name): Project
        {
            $this->name = $name;
            return $this;
        }
        
        public function getStatus(): string
        {
            return $this->status;
        }
        
        public function setStatus(string $status): Project
        {
            $this->status = $status;
            return $this;
        }
        
        public function getSort(): int
        {
            return $this->sort;
        }
        
        public function setSort(int $sort): Project
        {
            $this->sort = $sort;
            return $this;
        }
        
        public function getUser(): User
        {
            return $this->user;
        }
        
        public function setUser(User $user): Project
        {
            $this->user = $user;
            return $this;
        }
        
        public function getDepartment(): Department
        {
            return $this->department;
        }
        
        public function setDepartment(Department $department): Project
        {
            $this->department = $department;
            return $this;
        }
        
        public function getMembership(): string
        {
            return $this->membership;
        }
        
        public function setMembership(string $membership): Project
        {
            $this->membership = $membership;
            return $this;
        }
    }

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

    Новички не всегда задумываются, но Doctrine маппит данные (процесс называется гидрация) не через сеттеры, а делает это через Reflection API. Вот статья Marco Pivetta о том, как работает гидрация объектов: ocramius.github.io/blog/doctrine-orm-optimization-hydration

    Геттеры


    Геттеры ничем не лучше сеттеров. Они ровно также нам помогают нарушать инкапсуляцию.
    Конечно, не говорю про методы, которые нам нужны для транспорта данных (для чтения и создания DTO, для сериализации и т.д.).

    Ниже приведу код, который уже поражен проблемами, которые появились из-за возможности нам «удобно» читать поля. Код из головы, но он близок к тому, что видели мои глаза и штамповали мои руки.

    Представим некий домен заказа некого интернет-магазина. Допустим у нас есть хэндлер для обработки заказа по его ID, чтобы принять решение — пропускать заказ дальше через процедуры или нет:

    $order = $this->orderRepository->find($orderId);
    if ($order === null) {
         throw new OrderException('Order not found.');
    }
    
    if ($order->getStatus() === Order::STATUS_ACTIVE 
        && $order->getDeliveryDate() <= $date
    ) {
        $this->orderDeliveryService->handle($order);
    }
    

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

    $order = $this->orderRepository->find($orderId);
    $cityFreeLimit = $this->cityOrderService->getCityFreeLimit($cityName);
    
    if ($order->getCity() === $cityName 
        && $order->getTotalPrice() > $cityFreeLimit
    ) {
         $delivery = 0;
         $this->orderDeliveryService->deliveryOrder($order, $delivery);
         
         return;
    }
    
    // обрабатываем заказ не с бесплатной доставкой по текущему городу
    

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

    Все это оборачивается тем, что детали бизнес-логики приходится изучать в посторонних строках кода. По сути это очень сложный код, так как разобраться с тем, что он делает, становится тяжело. Нужно либо держать в голове, либо держать в голове коллеги, его точно всегда приходится много читать и вдумываться и постоянно плодить ошибки и баги, и много копипасты. Код раздувается процедурными «сервисами» и «менеджерами».

    Итог


    Код с сеттерами/геттерами заметно усложняет код, со сложным доменом и так бывает не просто, логика не помещается в единицу разума, но когда еще и паутина из кода, который воплощает «на самом» деле некие управляющие конструкции или частицы данных, мешается — становится довольно тяжело писать чистый, тестируемый, спокойный для нервной системы программиста код.

    К сожалению факт — большое число программистов на Symfony не до конца осознают проблемы анемичных моделей и считают такого рода объекты лишь хранилищем данных (DAO), плодят сервисы/менеджеры. Надеюсь — доводы выше подтолкнут задуматься о проблемах процедурного кода в ООП-обертке (хочу отметить, что в данном топике нет претензий к процедурному программированию).

    Ошибки и неточности готов быстро поправить, концептуально — уступок не будет :)

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

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 235

      +1

      Вопрос с гетткрами и сеттерами восходит к Java Bean где они используются повсеместно.И если в php по крайней мере они помогают с типизацией в Яве поля и без этого типизированы и их применение ближе к традиции чем к рационально у выбору.


      Что касается доктриновских сущностей. То как мне кажется добавлять в них логику более тяжёлую чем геттеры и сеттеры плюс Некоторые традиционные декораторы типа translatable и т.п. решение не очень перспективное. Просто зачастую разработчики не реализуют класс тяжёлой модели в которой как раз и задана логика того же delivery свойства и вызывает геттеры и сеттеры напрямую в сервисах.

        +1
        Спасибо большое. Да, наслышан про бины, про историю EJB и POJO :)

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

        Кроме того есть ряд доменов — простых и лаконичных с точки зрения описания в модели, но привычка — дело страшное и все летит к чертям :( Об это и написал.
          +2
          То как мне кажется добавлять в них логику более тяжёлую чем геттеры и сеттеры плюс Некоторые традиционные декораторы типа translatable и т.п. решение не очень перспективное.

          Такое утверждение таки требует аргументации )

          В статье приведены хорошие аругменты в пользу rich domain model, и отказа от анемии, включая то что анемия — возврат к старому доброму процедурному коду и утеря контроля над состоянием.

          Разобраться в типичном проектике с 3-мя папками со свалкой нескольких десятков сущностей, сотней сервисов и представлений, когда сущности представляют собой простыню геттеров-сеттеров занятие уже не особо преспективное. Это сложности для ввода новичков в проект и сильная привязка проекта к команде, которая может(по крайней мере пока) держать в уме реализованную в проекте БЛ. А если на проекте не останется людей которые его начинали ситуация ещё усложнится.

          По поводу translatable и т.п. — в итоге получаем то, что сущность представляет почему-то не доменную модель, а отражает UI-приложения(Поля сущности = интерфейс приложения, всякие translatable — исключительно UI). Я уж не хочу думать что будет когда в приложении появится несколько интерфейсов.
          Конечно при таком подходе совмещать в тех же сущностях БЛ малоперспективное занятие. И решается это проведением границ между отображениями и логикой — для UI/GUI есть DTO/структуры/массивы. Для выборок есть SQL, для выборок по полям сущностей доктрины есть DQL, и результаты DQL запроса вовсе не обязательно мапить на сущности.

          Ещё одна важная проблема анемичных моделей — юнит тесты. Анемичная модель это +1 зависимость во все тесты. Их будет сложнее читать/писать/поддерживать, поэтому про них бывает просто забывают и поступают как со старым легаси: добавил сервис — написал пачку интеграционных тестов и сойдёт. Недостатки интеграционных тестов перед юнитами я думаю не тема данного комментария и понятны тем кто их пишет.

          Пользовательский интерфейс — это не та вещь, по которой нужно проводить границы в приложении(сразу вспоминается Тостер с вопросами аля «Разделил админку и фронт на два приложения, подскажите как реюзать сущности?»).
        +4

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


        Но зачастую приходится их делать, для того, чтобы не вводить ещё один слой абстракции из-за того, что тулинг типа обработчиков форм не умеет работать с внутренними свойствами. Кстати, не понятно зачем в статье Symfony упомянут — ничего специфичного нет.


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


        P.S. Для геттеров не помешал бы "правильный" пример.


        P.P.S. Наверное, имелась в виду 'order === null'

          +6
          Конкретно для форм есть такая штука github.com/sensiolabs-de/rich-model-forms-bundle.

          По теме статьи, полностью согласен. Как не смешно, из за этого ушел из PHP разработки. Около двух лет назад пытался довести аналогичные доводы до команды, объяснить что используя сеттеры сами себе ставим палки в колеса, что такое инвариант, как его сохранить и тд. Дело оказалось крайне не благодарным, когда я заводил эту тему (не один раз) на меня смотрели с неслабой такой долей скепсиса. Плюнул на это дело, нашел другую работу, в требованиях написано DDD, на второй день задал вопрос тимлиду: «почему в коде только анемичные модели, DDD то будет?» на что получил ответ: «что такое анемия?» Через пару тройку месяцев ушел в go…
            +2

            И как на go с DDD? Я на одном сервисе попробовал как-то не очень результат нравится.

              +2
              С переходом на go задачи стали намного ближе к системному уровню чем к бизнес-прикладному. Тем не менее если надо что-то такое соорудить берем go-kit. Он фактически навязывает архитектуру портов-адаптеров и косвенно навязывает lite-ddd подход.
              Если смотреть по выразительности языков, то тут по моему мнению php выигрывает, соответственно и для ddd он лучше подходит (для полного счастья не хватает модификаторов области видимости на уровне модулей)
                +1

                Спасибо за наводку, гляну. Мне больше близки именно задачи бизнес-прикладного характера.

              0

              Меня как раз удерживает переход на go работа с базами данных. По сравнение с доктриной там сразу и все очень сложно. Особенно когда идёт речь о nullable которые из-за строго йтипизации приходится реализовывать структурой

                0

                Я кроме gorm ничего не использовал, но в его контексте как-то непонятно, что реализовать структурой, тип поля или всю запись? Если поля, то не структурой, а указателей рекомендованных способ. А структура для записи в целом

                  0

                  Т.к. go типизирванный язык то значение из базы данных null вызывает ошибку что ожитбается значение строки а фактическое знеачение nil Поэтому все такие поля нужно определять как например sql.NullString и т.п. И работа с этими полями становится сразу и очень напряжной.

                +2
                Наверно, лучше сказать «ушел из бизнес-разработки в более системную». Так-то есть проблемы с использованием DDD в зависимости от команды, а не ЯП (хотя практики и инфраструктура тоже влияет, конечно).
              +2

              думаю без знака восклицания будет правильно


              if ($this->isDelivered()) {
                  throw new OrderDomainException('Order already delivered.');
              }
                +2
                два чаю этому господину :) спасибо!
                +1
                Инкапсуляция это не сокрытие данных, это обьединение данных с методами над ними
                Тут она нарушается потому что логика работы над обьектом уходит наружу
                  0
                  Да :) разницу между сокрытием данных и инкапсуляцией знаю, но все же в нее объединяют кроме логики еще и сокрытие данных (часто), потому этим моментом тут пренебрег!
                  Вы правы!
                  +3

                  Maksclub Во-первых спасибо за статью, действительно это не самый однозначный (и широко освещаемый) вопрос.


                  Насколько я могу понять — описываемый вами подход ранее описывал Marco Pivetta в своём докладе "Doctrine ORM Good Practices and Tricks" (записи докладов есть у него на сайте, вот эта к примеру).


                  Во время просмотра его доклада и во время чтения вашей статьи, хотя я концептуально согласен и с аргументами Marco и с вашими — у меня тем не менее возникает несколько вопросов (возможно из-за неполного понимания), буду благодарен если вы их прокомментируете:


                  Первый вопрос:


                  В вашем примере "неубиваемого" объекта Order как будет выглядеть код, отображающий этот Order во view? Свойства объекта у вас приватные, методы реализуют операции над данными, но как отобразить эти данные пользователю?


                  Правильно ли я понимаю что (возможно) предполагается реализация некоего метода который будет возвращать данные entity в виде, необходимом для отображения? Или же несколько подобных методов на случай если требуется разная детализация данных.


                  К примеру в случае какого-нибудь Article мы можем хотеть для одного сценария иметь возврат только базовых данных, а в другом — более полных которые в свою очередь могут включать в себя данные из связанных entities (те же комментарии или имя автора), дёргать которые (и тем самым инициировать их загрузку из базы) в более простом сценарии нам не надо чтобы минимизировать количество запросов к базе данных.


                  Не придём ли мы в этом случае к ситуации что наша entity будет слишком много знать о том каковы сценарии её использования в приложении?


                  Второй вопрос:


                  Вы приводите пример метода для изменения статуса ордера, Marco приводит пример с пользователями и ролями. Хотя в ваших примерах в целом всё понятно — я не могу отделаться от ощущения что в общем случае при каких-то сценариях реализация этих методов для работы с данными entity может потребовать использования какого-либо внешнего объекта. В этом случае перед нами встаёт вопрос dependency injection для entity. Он, конечно, решаем, но на уровне ощущений не выглядит чем-то правильным.


                  Было бы очень хорошо чтобы вы раскрыли этот момент более подробно.

                    +3
                    Давайте сразу предупрежу — я не очень опытен, особенно касательно RichModel/DDD и всех этих дел. Потому тему свою ограничил инкапсуляцией, тк просто видел много кода, который становился сложным просто так, бесплатно и просто вижу те момент, где действительно можно упростить обслуживание кода в перспективе и контролировать его сложность.

                    По поводу сериализации сделал оговорки в статье для отступления на случай таких вопросов:
                    Конечно, тут не говорю про методы, которые нам нужны для транспорта данных (для чтения и создания DTO, для сериализации и т.д.).

                    То есть ответом на вопрос про Order — я бы использовал все же геттеры, просто жестко контроллировал их применение именно транспортом.
                    По этому кстати поводу знаю горячий дискус в Java тусовке с появлением Егора Бугаенко (который про объект могучий и прочее), он за то, что объект сам себя знает как сериализовать, тут я сторонник классических подходов.

                    Данный доклад Марко посмотрю, не смотрел. Спасибо большое!
                      0

                      Большое спасибо, буду разбираться дальше :)

                      0
                      По второму вопросу — не смогу на данный момент ответить.
                      Fesor мог бы подсказать по этому поводу
                        +1
                        Насколько я понимаю, во многом из-за него мы и имеем «глупые» сущности, которые, по сути, являются лишь хранилищами состояния, делегируя его управление во внешние сервисы. Это вызвано стремлением избежать превращение сущностей в «божественные объекты». В конце концов от active record с переходом на doctrine2 отказались по вполне определенным причинам.
                          +1

                          Скорее это вызвано ошибочным (в рамках ООП) разделением ответственности хранилища состояния и его контроля и/или неправильным пониманием, что такое сущность. Типа если состояние и логика сущности будут в одном объекте, то у этого объекта будет две ответственности. Хотя назначение объектов объеденять состояние и поведение.

                            +1
                            Я думаю у такого подхода есть свои минусы. Например в случае с глупой сущностью процесс публикации статьи выглядит так:
                            $service->publish($article);

                            В предлагаемом вами варианте:
                            $article->publish();

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

                              Естественно не дело. Поэтому метод паблиш статьи знает только то, что касается самой статьи. Например, проверит что статус допускает публикацию, выставит дату публикации, удалит префикс wip из заголовка и т. п. А остальное сделает сервис, вызвав в какой-то момент метод статьи., а не дергая 100500 геттеров и сеттеров. Которые юнит-теста и нормально покрыть может и не получится, кстати.

                                +1
                                А я думаю, что развязывание publish() и части описанного (логи, уведомления и пр., кроме сохранения в БД и безопасности) надо решать в том числе с помощью паттерна «Наблюдатель» и шины событий: внутри publish() надо генерить в шину событие. Проверка прав — это пусть контроллеры делают или middleware.
                                  +3
                                  ваше утверждение не конфликтует с тем, что написал VolCh
                                    0

                                    Одно другому не мешает. На практие именно на PHP часто такая (очень грубо) схема:


                                    class PublishService 
                                    {
                                      public __constructor(PostRepository $repository, EventBus $bus) {}
                                    
                                      public publishPost(PostId $postId) {
                                        $post = $this->repo->get($postId);
                                        $post->publish();
                                        $events = $post->takeEvents();
                                        $this->bus->send($events);
                                    }
                                    }
                                      0
                                      Ну да, только я события в шину внутри сущности пихаю, мне так удобнее). Шину через SL получаю в конструкторе сущности.
                                        +1

                                        Я стараюсь придерживаться классического подхода, когда конструктор вызывается исключительно для создания новой сущности как сущности :), а не для создания объекта для представления сущности в рамках конкретного сервиса.

                                          0
                                          Кто же этот подход «классическим» объявил? Это сложилось из-за того что в Doctrine ORM нет возможности в сущности ничего внеднять через конструктор.
                                            0

                                            Так туда и не надо ничего внедрять, кроме того, из чего состоит непосредственно сущность.

                                              0
                                              Отсюда и проблема анемии сущностей. В том виде, в котором сейчас принято работать с Doctrine ORM: «не надо туда ничего внедрять, кроме того, из чего состоит сущность», проблема анемии останется там где и была.
                                              Тут уже писали — было поведение в сущности, изменились требования, теперь это поведение требует зависимость, поведение переезжает в сервис.
                                                +3
                                                Отсюда и проблема анемии сущностей. В том виде, в котором сейчас принято работать с Doctrine ORM: «не надо туда ничего внедрять, кроме того, из чего состоит сущность», проблема анемии останется там где и была.

                                                У вас попутаны причина и следствие.
                                                Внедрять сервисы в сущность в принципе нехорошо. Что с доктриной что без неё.

                                                Тут уже писали — было поведение в сущности, изменились требования, теперь это поведение требует зависимость

                                                Бизнес-требование само по себе никогда не «требует» зависимость. Зависимость может требовать выбранная вами реализация, которую вы по непонятным причинам посчитали единственно верной, и выстраиваете из этого свою позицию, будто бы подразумевая что альтернитив не существует, что на мой взгляд не корректно.

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

                                                P.s. Почитал ветку ниже. Ещё раз — суть сих действий в том чтобы изолировать изменение состояния и важные бизнес-правила внутри наших сущностей, рич модел не о том чтобы весь код приложения находился в сущностях.

                                                А где тогда должна быть бизнес логика, которая юзает зависимости, например, если при рассчете времени доставки заказа нужно опросить внешнее API? В приложении этот API предположим, представлен как DeliveryService внутри которого http клиент. Можно ли его внедрять в доменные сервисы?

                                                Как я выше писал — бизнес логика не юзает зависимости.
                                                Сходить во внешний сервис — это не бизнес-логика, это простейшая координация действий. Не происходит изменения стейта, нет риска нарушения инвариантов, это простое чтение данных. Этим может заниматься сервис, для этого нам не нужна наша сущность, и поэтому анемичной она не станет. Если результат из сервиса нужен для логики сущности — вызовите метод сущности передав туда результат который вернул сервис.
                                                  0
                                                  Сходить во внешний сервис — это не бизнес-логика, это простейшая координация действий. Не происходит изменения стейта, нет риска нарушения инвариантов, это простое чтение данных. Этим может заниматься сервис, для этого нам не нужна наша сущность, и поэтому анемичной она не станет. Если результат из сервиса нужен для логики сущности — вызовите метод сущности передав туда результат который вернул сервис.


                                                  А если мне на основании стейта нужно принять решение, ходить ли наружу или нет, а по результатам хождения наружу нужно тоже изменить стейт, здесь тоже предложите в сервис вынести?
                                                  Пример требований:
                                                  При проверке статуса счета (Invoice), если счет еще не был закрыт, нужно проверить его состояние в платежной системе, проверить соответствие суммы и, если все верно, изменить параметры и состояние счета, а потом закрыть его. Я это делаю в методе Invoice::checkStatus(), в Invoice внедрен шлюз к ПС, который и используется для этой проверки. Это по вашему не бизнес-логика, а «координация действий»? Удивительный темин, кстати.

                                                  Внедрять сервисы в сущность в принципе нехорошо. Что с доктриной что без неё.


                                                  Мне еще не разу не смогли привести конкретный пример, когда это реально вредило бы.

                                                  Внедрять сервисы в сущность в принципе нехорошо. Что с доктриной что без неё.


                                                  Ошибаетесь. Вы фантазируете. Я не говорил, что мое единственно верное. Я хочу выслушать аргументы другой стороны. В комментариях здесь же я писал, что штука это рабочая, но я не понимаю, почему она так популярна, если постоянно возникает столько вопросов.

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


                                                  Я нигде не утверждал подобное. Снова ваши додумки.
                                                    +2
                                                    При проверке статуса счета (Invoice), если счет еще не был закрыт, нужно проверить его состояние в платежной системе, проверить соответствие суммы и, если все верно, изменить параметры и состояние счета

                                                    Это уже не просто решение на основе стейта, а полноценный процесс затрагивающий несколько операций, и в котором нужно контроллировать консистентность состояния в двух системах.

                                                    Почему не делать это в сущности — сущность представляет некую часть вашего и делает какие-то полезные вещи, синхронизация конекстов не её задача. Вот и всё.

                                                    Для описания сложных процессов есть Саги/Процесс-менеджеры, по сути это тоже сервисы приложения, просто формально чуть другое предназначение, может быть состояние(ивенты), но это сложно/надо прикручивать/большинству незнакомо(больше рисков сделать лишь хуже) и в принципе для описанного кейса оверинжиниринг, можно сделать просто сервис куда поместить логику синхронизации счетов.

                                                    Это всё не противоречит rich-domain-model и может с ними сосуществовать. Просто не нужно переходить из крайности в крайность, и как только появилась логика в сервисах впиливать геттеры/сеттеры в сущности.
                                                      –3
                                                      Это уже не просто решение на основе стейта, а полноценный процесс затрагивающий несколько операций, и в котором нужно контроллировать консистентность состояния в двух системах.


                                                      Что то вы опять нафантазировали. Какую консистентность контролировать? Просто спросить, оплачен ли счет, и на основе этого изменить стейт.

                                                      class Invoice 
                                                      {
                                                          private $payment_gateway;
                                                      
                                                          public function checkStatus()
                                                          {
                                                               if (!$this->isClosed()) {
                                                                   $data = $this->payment_gateway->getData($this->id);
                                                                   
                                                                   if ($this->validate($data)) {
                                                                       $this->payment_method = $data['payment_methiod'];
                                                                       $this->close();
                                                                   } 
                                                                   
                                                               } 
                                                          }
                                                           
                                                      }
                                                      
                                                      

                                                      И полезная вещь здесь — проверка статуса платежа.
                                                      А вы AppService, оверинжиниринг это будет. Вместо одного простого метода целый класс прикладного сервиса, с регистрацией в контейнере естественно))).
                                                        +3

                                                        А зачем счёту знать что-либо о платёжном шлюзе? В вашем случае именно так и получается. По-моему, тут зависимости ровно в другую сторону должны быть направлены. А еще лучше, если счёт не будет ничего знать о шлюзе, а шлюз о счёте.

                                                          –1
                                                          А вы попробуйте реализовать, то что вы сказали «счет ничего не будет знать о шлюзе, шлюз о о счете», посмотрим насколько громоздким и объектно-оринтированным будет этот код.
                                                            +2

                                                            Волне нормальным. Сервис, у которого в зависимостях шлюз и, опционально, репозиторий инвойсов. И в методе checkStatus параметром инвойс или его ид (тогда репозиторий и нужен в заисимостях)


                                                            Сейчас у вашего инвойса минимум две отвественности: своё состояние и его синхронизация с внешним сервисом, по какому-то внешнему запросу. То есть кто-то вне инвойса знает, что этот инвойс не самодостаточен, может быть рассинхронизирован с чем-то, но типа не знает с чем, хотя и принимает решение в какой момент времени нужно синхронизироваться. Почему вообще не вынести логику синхронизации вовне полностью?

                                                              0
                                                              Сейчас у вашего инвойса минимум две отвественности: своё состояние и его синхронизация с внешним сервисом, по какому-то внешнему запросу.

                                                              Свое состояние это не ответственность. Ответственность это поведение.

                                                              Волне нормальным. Сервис, у которого в зависимостях шлюз и, опционально, репозиторий инвойсов. И в методе checkStatus параметром инвойс или его ид (тогда репозиторий и нужен в заисимостях)


                                                              И везде где нужно проверить статус, придется обращаться к этому сервису, передавая ему уже имеющийся инвойс или id

                                                              CheckService::checkInvoice($invoice);

                                                              Это процедурная декомпозиция.
                                                                +1

                                                                Вот ваш метод close() реализует поведение сущности. Инвойс знает как себя закрыть. когда закрывать — вне области его отвественности.


                                                                Объектная декомпозиция:


                                                                class InvoiceSyncService {
                                                                  public __constructor(PaymentGate $paymentGate) {...}
                                                                
                                                                  public syncWithPaymentGate(Invoice $invoice): void {
                                                                    if ($invoice->isClosed()) return;
                                                                    $data = $this->paymentGateway->getData($invoice->id);
                                                                    if (!$this->validate($data)) return;
                                                                    $invoice->closeOnPayment($data['paymentMethod']);
                                                                  } 
                                                                }
                                                                  0
                                                                  И все таки мне кажется что если так с Invoice обходиться, то получится, что он будет почти что структурой данных, ведь методы isClosed() и close() это практически геттер и сеттер, не будет ли этого поведения слишком мало (анемия)?:

                                                                  class Invoice 
                                                                  {
                                                                  
                                                                      private const CLOSED = 100;
                                                                  
                                                                      pubic function isClosed() : bool 
                                                                      {
                                                                           return $this->status == self::CLOSED;
                                                                      }
                                                                  
                                                                      public function close() {
                                                                           $this->status = self::CLOSED;
                                                                           $this->triggerEvent(new InvoiceClosedEvent($this->id, $this->amount));
                                                                      }
                                                                  
                                                                  }
                                                                  
                                                                  
                                                                    +2

                                                                    В каких-то случаях да, мало поведения будет. И практически те же геттеры/сеттеры с технической точки зрения.


                                                                    Но с точки зрения ООП вы уже инкапсулировали знания о наличии свойства status в принципе, не говоря уже о том, какое значение отвечает за закрытое состояние.


                                                                    Ну и скорее всего в Invoice у вас будет свойство invoices типа InvoiceItem[], для которого тупые сеетеры по идее должны быть вообще исключены, а общение с ними клиента класса Invoice исключительно через методы типа addInvoiceItem(Product $product, int $amount) и т. п., которые, скорее всего, будут не просто делегировать вызовы работы с массивом, а будут, например, проверять итемы на валидность, вести накопительные итоги и т. п.

                                                                      +3
                                                                      Ок, спасибо за терпеливые разъяснения, буду обдумывать.
                                                    0
                                                    Сходить во внешний сервис — это не бизнес-логика, это простейшая координация действий. Не происходит изменения стейта, нет риска нарушения инвариантов, это простое чтение данных. Этим может заниматься сервис, для этого нам не нужна наша сущность, и поэтому анемичной она не станет. Если результат из сервиса нужен для логики сущности — вызовите метод сущности передав туда результат который вернул сервис.


                                                    Мне кажется ответ базируется на удобном интерпретирование вопроса. Ходить во внешний сервис — нет это не бизнес-логика, поэтому и о HTTP клиенте сущность не будет знать. Но как быть если все таки существуют инварианты для подсчета времени доставки? Что если время доставки зависит от статуса заказа (на складе, запакован уже и тд)? Или от других данных состояния: тип, размер? Выносить все эти проверки в сервис, где считается время доставки и устанавливается в сущность? Сущность все такая же анемисная, и метод `delivery` все тот же «сеттер» устанавлиющий несколько свойств сущности (проверяет часть инвариантов, но не все связанные с поведением доставки).
                                                      +1

                                                      Если сервис действительно необходим сущности, то для сервиса создаётся интерфейс, инстанс сервиса (с заинжекченным, например, http клиента) передаётся сущности как аргумент методов, которым он нужен.


                                                      Но вот в данном кейсе скорее всего лучше будет сделать DeleveryService, который будет работать с сущностью Order через методы типа startDelivery(\Datetime $startTime, \DateInterval $plannedDuration), finishDelivery($finishTime), cancelDelivery($cancelTime) и т. п. При этом сущность будет отвечать за свои инварианты, типа возможности начать, закончить или отменить доставку из текущего состояния (неоплаченный заказ нельзя доставлять или нельзя отменить доставку, которая ещё не началась), соблюдения последовательности таймстампов и т. п. И у меня уже язык не повернётся назвать её анемичной.

                                                    +1

                                                    Не полностью переезжает, а только та часть, которая сущности не касается. Сервис становится чем-то вроде декоратора к сущности.

                                                      0
                                                      А таким образом не теряется cohesion? Поведение, решающее одну задачу не становится как бы «размазанным» по нескольким классам?
                                                        0

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

                                                          +1
                                                          Ладно, я подумаю над этим, может действительно надо поменьше на свои сущности возлагать. Что-то в этом есть.
                                                  +3

                                                  Эванс, если не ошибаюсь. Суть в чём: сущность длительно живущий объект, создающийся только один раз, а потом лишь изменяющийся. Ну и, может быть, когда-то уничтожается.

                                                    0
                                                    У него в 'blue book' ничего не говорится о том, что в сущности нельзя внедрять зависимости и вообще о конструктора, и внедрении зависимостей.
                                                      +1

                                                      Не смог вспомнить кто был автором именно подхода с конструктором, но вспомнил, что он выведен из правила Эванса " Определение класса должно быть простым и строиться вокруг непрерывности и уникальности цикла существования объекта.". В принципе, конечно, можно сделать конструктор чисто технической деталью и использовать его исключительно в фабриках и репозиториях. Тогда внедрение зависмостей через конструктор будет выглядеть не так ужасно на уровне интерфейсов доменной модели.


                                                      Но Вернон точно писал о том, что ужасно внедрять зависимости в сущности и VO в принципе. За исключением, конечно, других сущностей и ВО, но тут сложно говорить о зависимости, это часть их стейта по сути.

                                +2

                                Как варианты решения первой задачи (единственно правильного нет):


                                • геттеры (в "чистых" rich моделях сущностей часто без префикс get, типа order->status()
                                • единый DTO (для PHP можно массив)
                                • DTO под юзкейс (большое смешение оиветственностей часто получается типа orderForRegularUser и orderFirAdminUser)
                                • адаптеры или view model, в том числе с рефлексией или подобными "хаками" или использованием одного из предыдущих способов

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


                                По второму: по умолчанию, если надо изменять две сущности синхронно и/или зависимо, то этим занимается какой-то сервис модели.


                                Иногда практично передать вторую сущность или сервис как параметер в метод первой.


                                Классический DI в сущностях обычно кричит об очень неудачном распределении ответственностей в модели в целом.

                                  0
                                  единый DTO (для PHP можно массив)

                                  Лучше это назвать CQRS. DTO и особенно массивы в большинстве случаев, по-моему, плохая и распространенная практика сокрытия аргументов функции, а CQRS лучше объясняет, когда подобная идея может успешно применяться. В read моделях и read логика кое-какая может быть.
                                    0

                                    CQRS отдельная тема. Я про представление сущности для view. Объект сущности уже есть в памяти процесса, надо какие-то данные передать во view, например, новое состояние после изменения. По CQRS на query операции нам и сущности-то не нужны.

                                  0
                                  я не могу отделаться от ощущения что в общем случае при каких-то сценариях реализация этих методов для работы с данными entity может потребовать использования какого-либо внешнего объекта. В этом случае перед нами встаёт вопрос dependency injection для entity.
                                  Можно посмотреть такое понятие, как aggregate root. То есть создавать сущности, которые уже содержат другие сущности.
                                  Но если речь об общении между доменами (границы между которыми определяет разработчик), и тем более об общении с внешним миром, то это уровень сервиса приложения.
                                  Чтобы говорить конкретнее, то лучше всего оперировать конкретным бизнес-сценарием.
                                    +1
                                    По первому вопросу, зачем вам сущность для отображения? Обычный SQL и результат в DTO или в массив и на вывод пользователю (ReadModel)
                                    По второму вопросу, нужно больше деталей, т.к. все оч сильно зависит от кейса, но в любом случае другой объект можно передать как аргумент в сам метод, и не нужно никакого DI, но опять же все оч сильно зависит от задачи, и как спроектирован домен.
                                    0
                                    Под инкапсуляцией обычно понимают сокрытие данных, поведения, деталей и условий.

                                    Вот и неверно понимают, инкапсуляция это немного другое:
                                    Инкапсуляция — упаковка данных и функций в единый компонент
                                      0
                                      выше habr.com/ru/post/469323/#comment_20687065
                                      уже ответил на аналогичный комментарий, вы правы!
                                        0

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

                                          0
                                          Вы путаете сокрытие и инкапсуляцию:
                                          bit.ly/2n0MRwe
                                        –7

                                        Автор сам придумал себе проблему вынеся логику в модели. Да модели следует рассматривать как простые DAO. Это механиз мапинга ваших данных в БД. Не более того. Всю логику при надо вынести отдельно к примеру в репозитории, контроллеры и т.д., а чтобы защитить себя от случайного использования модели напрямую, можно написать доктрин листенер, который будет проверять к примеру какой-то флаг у энтити к примеру isExpectedUpdate перед изменением. Этот флаг будет устанавливать ваш код бизнес логики, и если он false, листенер ругается и отменит flush. И не надо морочить голову с инкапсуляцией.


                                        Если бы я увидел логику в слое ORM отличную от computed properties, отправил бы это на переделку

                                          +1

                                          Механизм маппинга — это как раз ORM, доктрина в данном случае. Сущности и репозитории слою ORM не принадлежат, они вход/выход для него.

                                            +2

                                            Как раз таки бизнес-логики не должно быть в контроллерах. Плавали, знаем...

                                              –1
                                              Хорошо представим что в методе isDelivered потребовалось что-то кроме полей самой модели, что тогда делать? Инджектить как-то зависимость в модель? Передавать зависимость постоянно в метод isDelivered($someService). Это неправильно. Есть репозитории в которые как нормальные сервисы можно инжектить зависимости. Автор отвечает что, а зачем туда зависимости, модель только за свои данне отвечает. Ну и получится в итоге что либо isDelivered не может быть вычеслен на уровне модели в принципе, либо isDelivered на самом деле не является тем чем он есть (не отвечает в полной мере на вопрос так доставлен же товар или нет). Ну т.е. в более сложном сценарии isDelivered скорее всего сам по себе переедет куда-то в другое место.

                                              И как автор к приеру выбирает из базы данных все заказы которые delivered? Пишет что-то вроде SELECT FROM WHERE status = «delivered», все равно логика уехала из модели. И скорее всего будет перемещена в репозиторий. Ну так зачем размазывать логику везде, уже пиши все в репозитори.

                                              А потом автор прикрутит какой-то сериалзитаор и он ему на 1000 моделях понадергает публичные методы delivered т.д. и хорошо если это просот сильно замедлит скрипт, хуже если эти публичные методы приведут к каким-то side effects нежелательным.

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

                                              И если уж автор решил заняться инкапсуляцией, тогда я ему надо посмотреть в сторону паттернов Command либо Workflow. Грубо говоря отдельный слой, для работы с моделями, а с самими моделями напрямую не работать вообще.

                                              А в подходе автора получается ни туда ни сюда. Вроде инкапсуляция есть, но не в том месте где она нужна.
                                                +1
                                                Хорошо представим что в методе isDelivered потребовалось что-то кроме полей самой модели, что тогда делать? Инджектить как-то зависимость в модель? Передавать зависимость постоянно в метод isDelivered($someService).

                                                Если состояние «доставлено» перестало быть обычным флагом, то, возможно, стоит задуматься о выделении этого состояния в отдельный класс. Вполне может получиться, что «доставка» — это отдельная сущность со своей логикой. Это сильно зависит от контекста.


                                                И как автор к приеру выбирает из базы данных все заказы которые delivered? Пишет что-то вроде SELECT FROM WHERE status = «delivered», все равно логика уехала из модели. И скорее всего будет перемещена в репозиторий. Ну так зачем размазывать логику везде, уже пиши все в репозитории.

                                                Есть мнение, что сущности и логика в них предназначены, главным образом, на запись. На чтение можно использовать обычные массивы, DTO и т.д. Я думаю, что в этом случае одно другому не мешает, т.е. логика никуда не уезжает.


                                                А потом автор прикрутит какой-то сериализатор и он ему на 1000 моделях понадергает публичные методы delivered т.д. и хорошо если это просто сильно замедлит скрипт, хуже если эти публичные методы приведут к каким-то side effects нежелательным.

                                                И вообще в современном мире когда все взаимодействие идет с бекендом обычно через АПИ, вообще вопрос инкапсуляции решается не сеттерами и геттерами, а группами сериализации, которые решают что видно извне и формируют интерфейс взаимодействия.

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


                                                И если уж автор решил заняться инкапсуляцией, тогда я ему надо посмотреть в сторону паттернов Command либо Workflow. Грубо говоря отдельный слой, для работы с моделями, а с самими моделями напрямую не работать вообще.

                                                В конце концов кто-то всё равно должен работать с сущностями.

                                                  +1

                                                  Если в сущности в методе isDelivered потребовалось что-то кроме полей самой сущностей и полей связанных с ней, то выход очевиден — вынести этот метод из сущности в сервис.


                                                  Модель — это не только сущности, это сущности+объекты-значения+доменные сервисы+интерфейсы репозиториев+(иногда)фабрики. А вот API ендпоинты, сериализация и т. п. — вне модели. Делаете на выходе из модели DTO и уже его сериализируете.

                                                    0
                                                    А я не согласен. Я бы подумал, может и в сущность зависимость добавить, например если эта зависимость используется в большинстве методов сущности, а в isDelivered() три четверти кода используют состояние сущности.
                                                      +2
                                                      Тогда вы нарушите правило изоляции слоёв (clean architecture). Хотя я не совсем понимаю, какого рода зависимость вы хотите добавлять в сущность.
                                                        0
                                                        Нет, не нарушу. Посредством интерфейса можно внедрять что угодно. Например EventBus.
                                                          +1
                                                          Да можно получать этот EventBus даже из глобального состояния, кто вам запретит. Нарушит это в том плане, что доменный слой (бизнес-логика) будет знать о слое приложения.
                                                            0
                                                            А можете объяснить, каковы последствия этого нарушения? Связь же можно сделать посредсвом интерфейса, это тоже плохо? К тому же помимо сущностей есть бизнес-сервисы, это тоже часть БЛ, но в них зависимости все внедряют, в т.ч. и EventBus. Это разве не будет нарушением?
                                                              0
                                                              Посмотрите мой комментарий ниже, чтобы разговаривать об одном.

                                                              Я не знаю, о каких конкретно бизнес-сервисах вы говорите. Есть Application Services, есть Domain Services, и Event Bus, бывает, внедряется в первые, а лучше и сразу в инфраструктурный Persistence (в зависимости от роли). Могу представить в вырожденном случае даже использование этого паттерна в одной доменной сущности. Это всего лишь способ коммуникации внутри приложения, альтернативный обычному вызову "object.method(...arguments)".
                                                                0
                                                                Под бизнес-сервисами имею ввиду Domain Services. Если следовать логике, что домен не должен ничего знать о приложении, то тогда внедрение зависимостей типа EventBus в Domain Services будет нарушением правил чистой архитектуры? В доменные сервисы много раз видел как внедряются репозитории, это нарушение?
                                                                  0
                                                                  Это Application Service, стало быть. Application восстанавливает домен в памяти (путём получения необходимых данных), отдаёт ему команды, получает от него события об изменениях состояния и решает, что с ними делать (в основном сохранить и/или разослать).
                                                                    0
                                                                    С EventBus разобрались, все кто ее используют это должны быть в Application слое. А где тогда должна быть бизнес логика, которая юзает зависимости, например, если при рассчете времени доставки заказа нужно опросить внешнее API? В приложении этот API предположим, представлен как DeliveryService внутри которого http клиент. Можно ли его внедрять в доменные сервисы?

                                                                    И все таки я еще про внедрение репозиториев в доменные сервисы хотел уточнить? Можно ли их туда внедрять или нет? Если нет, что тогда могут доменные сервисы? Если да — почему тогда нельзя внедрять репы в сущности?
                                                                      +1
                                                                      Если нет, что тогда могут доменные сервисы?
                                                                      Изменять состояние соответствующих доменных сущностей в соответствии с некоторыми инвариантами.
                                                                      почему тогда нельзя внедрять репы в сущности?
                                                                      Тут мой комментарий, вот комментарий EvgeniiR. Это касается сущностей. Я настаиваю на строгом определении и касательно сервисов (код может коммуницировать только с «поддоменами»), чтобы не размывать границы слоёв, но кто-то может использовать «доменный сервис» более широко. Но сущности — однозначно последняя точка «дерева» выполнения приложения.
                                                                      А где тогда должна быть бизнес логика, которая юзает зависимости, например, если при расчете времени доставки заказа нужно опросить внешнее API?
                                                                      В сервисе приложения для этого юзкейса. Сервис может быть с логикой для выяснения, откуда брать это deliveryTime (по возможности спросив у сущности), а не только тонкой прослойкой. Все данные для изменений состояния должны быть у сущности или в команде.
                                                                        0
                                                                        Я вас понял, спасибо. В общем в сущностях у нас данные и код для соблюдения инвариантов (согласованноси данных). В сервисах у нас все остальное поведение, включая обработку событий сущностей.
                                                                        Мне это не близко. Напоминает процедурную декомпозицию: сущности — структуры данных (пусть и с инвариантами), сервисы — поведение. Это юзабельно, но мне не заходит, как то слишком мало при таком подходе могут сущности, мало инкапсулируют.

                                                                        Резюмируя по теме статьи: получается, что если при использовании сеттеров инварианты не страдают, то ничего плохого в их использовании в сущности нет?
                                                                          +1

                                                                          Код для соблюдения инвариантов в сущности — это свойство "правильной" сущности, по-моему, но не её цель. Сущность должна делать что-то полезное, кроме дачи гарантиий соблюдения инвариантов. А если она делает что-то полезное, то непонятно зачем сеттеры

                                                                            0
                                                                            Так вот и я говорю, что должна, а чтобы она могла это делать, нужны зависимости, а внедрять их считается плохим тоном, как мне тут пытаются объяснить.
                                                                              0

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

                                                                            +1
                                                                            если при использовании сеттеров инварианты не страдают
                                                                            Инварианты не страдают, потому что они прописываются в ТЗ. В вашем подходе получается, что в одном месте инварианты сущности и инварианты приложения.
                                                                            как то слишком мало при таком подходе могут сущности, мало инкапсулируют
                                                                            Максимальная инкапсуляция — у God Object. Не знаю таких целей в разработке, как достигнуть расчетной инкапсуляции. Только лишь взять на себя то, за что отвечаешь и избавиться от лишних знаний.
                                                                            Принцип «толстая модель» — это что-то из нулевых, по-моему. Но чуть позже в качестве «хороших» практик распространилась слоистая архитектура, в которой логика внутренних слоёв не зависит от внешних.

                                                                            Вы выше предполагаете, что в вашей логике могут понадобиться понадобиться данные извне для каких-то решений. Это по сути требование репозитория. У меня окончательно сформировался к вам вопрос: вы считаете нормальным внедрять репозитории в сущность, когда бизнес-логика требует каких-то посторонних для сущности данных?
                                                                            Что насчет внедрения других команд к другим доменам (через интерфейс, конечно), которые несомненно могут быть вызываться по сложным условиям бизнес-логики со сложными аргументами?
                                                                            Вызов entity.command(arguments) принципиально может заключать в себе всю логику и вызываться около входной точки приложения? И сущность состоит из ряда таких методов?

                                                                            Или часть бизнес-логики уровня приложения можно отправить в сущность, часть в вызывающий сервис в зависимости от оценочного понимания, где и что будет лучше?
                                                                              0
                                                                              Максимальная инкапсуляция — у God Object. Не знаю таких целей в разработке, как достигнуть расчетной инкапсуляции.

                                                                              Я знаю, я нигде и не говорил, что должен быть God Ocject. Зачем вы его сюда примешиваете? В моем заминусованном примере Invoice не God Object. Инкапсуляция данных и поведения в объектах должна быть, иначе это не ООП, а процедурное программирование со структурами данных.

                                                                              Инварианты никогда не страдают, потому что они прописываются в ТЗ.

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

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

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

                                                                              entity.command(arguments)

                                                                              Да я считаю, что в контроллерах можно так делать. Достать сущность, вызвать метод, показать результат выполнения.
                                                                                +1
                                                                                Я знаю, я нигде и не говорил, что должен быть God Object.
                                                                                Достать сущность, вызвать метод, показать результат выполнения.
                                                                                Это как раз и получается God Object (сущность) — одна модель является несколькими кусками приложения. Лучше уж тогда разделять на сервисы, которые работают с чистыми структурами (чистый процедурный стиль), чем так, по-моему.
                                                                                все больше «Это плохо потому что так написано там то, это какие-то новые пути для ошибок, побочные эффекты», неубедительно.
                                                                                Как хотите, разумеется. Я лишь предлагаю решение для борьбы со сложностью. Если вы по какой-то причине со сложностью не боретесь, то моих ораторских данных не хватит вас убедить начать бороться. Это вообще tacit knowledge, мне тоже когда-то бесполезно было это говорить, да и сейчас многое бесполезно — просто не пойму проблемы.
                                                                                  0
                                                                                  Ладно, спасибо и на этом.
                                                                                    0
                                                                                    Это как раз и получается God Object (сущность) — одна модель является несколькими кусками приложения.

                                                                                    Нет, не будет это God Object, так как God Object все делает сам, а если есть делегирование другим объектам, то это нормальная инкапсуляция. Если следовать вашей логике, то все фронт-контроллеры это God Object, так как под Application::run() скрывается работа всего приложения.
                                                                                    В моем примере god object нет.
                                                                                      0
                                                                                      Если вы по какой-то причине со сложностью не боретесь, то моих ораторских данных не хватит вас убедить начать бороться.

                                                                                      Я борюсь со сложностью, с чето вы взяли что нет? Только я пытаюсь бороться объектной декомпозицией, а вы предлагаете процедурную.
                                                                                      Это вообще tacit knowledge, мне тоже когда-то бесполезно было это говорить, да и сейчас многое бесполезно — просто не пойму проблемы.

                                                                                      Так может просто нет никаких весомых причин не внедрять зависимости в сущности, вы об этом не думали?
                                                                                0
                                                                                Но сущности — однозначно последняя точка «дерева» выполнения приложения.

                                                                                Скорее не последняя точка, а самые глубокие точки по дереву.

                                                                                0

                                                                                Я бы сделал интерфейс DeliveryService в доменной области, от которого зависят (по ситуации) или доменный сервис, или конкретный метод сущности. По умолчанию скорее первый вариант. И какой-то адаптер который существующий DeliveryService приводит к моему интерфейсу. Если существующий DeliveryService под моим полным контролём, то он будет имплементировать интерфейс. Если нет — введу адаптер, который будет имплементировать и получать существующий как зависимость.

                                                                              +1

                                                                              Репозитории, вернее их интерфейсы — это специфичный бизнес-сервис по сути. У меня в коде они обычно лежат вместе с сущностью, класс User и интерфейс UserRepository определенно будут в одном неймспейсе, что типа App\Domain\User. А вот какой-нибудь DoctrineUserRepository или RedisUserRepository определённо будут в совсем другом неймспейсе, вне домена App\Infra\Persist

                                                            +1
                                                            Возможно, вам лучше использовать паттерн Active Record (Laravel Eloquent, Yii) и не мучаться с Doctrine. Многие решения, примененные в ней, направлены на совсем иной стиль разработки. В отличие от Active Record.
                                                            –5
                                                            1. Статья не относится к symfony
                                                            2. Статья вводит в заблуждение новичков.
                                                            3. Статья «ниочем»

                                                            Автору желаю скорейшего просветления и рекомендую к прочтению книги Мэтт Зэнсдтра PHP Объекты и шаблоны, документацию по doctrine2, документацию по symfony 4+.
                                                            Без обид.
                                                              +2
                                                              Выше уже рекомендовали видео Marco Pivetta (Doctrine), прошу посмотреть:
                                                              youtu.be/WW2qPKukoZY?t=962

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

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

                                                                  +4

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

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

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

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

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

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

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

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

                                                                      Аннотации — один из ЧЕТЫРЕХ способов задать конфигурацию для маппинга на сущность (аннотации, xml, yaml, php конифгурация)
                                                                      В примере под спойлером есть аннотации

                                                                      Не знаю зачем я вам привел пример с Марко, наверное показать, что тема, поднятая в топике — за пределами документации, на изучение которой вы меня толкаете :) Что как бы подразумевает ваши намерения, вот вам и скинул — тоже пообразовывайтесь.

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

                                                                      Вы в ответе обращаетесь сразу к нескольким людям.
                                                                        –3
                                                                        У вас к 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, он заругается.

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

                                                                            давайте оставим беседу с вами

                                                                            я пойду опыта набираться, вы перестанете минусы получать от «ужасных» и неумелых хабравчан

                                                                            либо + 10 баллов вам за троллинг
                                                                          +2
                                                                          (публичные геттеры и сеттеры являются неотъемлемой частью сокрытия данных и реализации).

                                                                          Заблуждение, по-моему. Сами слова "геттеры" и "сеттеры" обычно оззначают, что они практически предоставляют прямой доступ к внутренним свойствам объекта. Формально они защищены, да, но по "ментальному конвешену" рни просто акцессоры к свойствам, пускай и дающие какие-то гарантии типа, что статус меняется исключительно по какому-то флоу, из любого в любой перевести нельзя, но вы, наверное, очень удивитесь увидев в реализации метода User::setStatus() обращение к внешнему сервису и не увидев свойства $user. Ну или протсо вэтом методе не только присвоение значения внутреннему полю, но и, например, изменение значения кучи других свойств, если параметер метода "ACTIVE"

                                                                            –4
                                                                            Вам сударь пример.
                                                                            <?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;
                                                                                }
                                                                            
                                                                            }
                                                                            

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

                                                                            постыдились бы своих слов.
                                                                              +4
                                                                              мы воюем с вами на разных полях

                                                                              зачем вы тащите сюда в комментарии примеры, как можно заммапить Доктрину на сущност (кстати, приводя при этом ОДИН!!! пример из четырех возможных)
                                                                              кроме того в вашем примере явно сеттеры и геттеры лишние, тк дата мапперу им начхать

                                                                              не пишите мне пожалуйста более, мы с вами говорим на разных языках
                                                                                –4
                                                                                зачем вы тащите сюда в комментарии примеры, как можно заммапить Доктрину на сущност

                                                                                Потому что в вашем примере есть пример для Project и Order при этом только один из них относится к doctrine, и про него вы задаете «Риторический вопрос», а в Order не относится к доктрине — но при этом вы его обсуждайте :)
                                                                                кстати, приводя при этом ОДИН!!! пример из четырех возможных

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

                                                                                Это далеко от понимания вами моего кода.
                                                                                В моем примере как раз таки нет сеттера и это как раз показывает что ваши «проблемы с инкапсуляцией» выдуманы вами. Также в моем примере показана инкапсуляция которая дает клиентскому коду только публичные методы доступа.

                                                                                Я понял что вам статьи нужны ради галочки, а не ради решения реальных проблем.
                                                                                Пишите побольше таких статье чтобы понять насколько вы глупы.
                                                                                  +3
                                                                                  Также в моем примере показана инкапсуляция которая дает клиентскому коду только публичные методы доступа

                                                                                  Термин «инкапсуляция»(encapsulate — заключать внутрь чего-либо, в капсулу) говорит нам о том что данные и работа с ними должна происходить в одном месте. В вашем же коде состояние объекта можно вытащить наружу через геттер и работать с ним.
                                                                                  Вывод — нет в вашем коде инкапсуляции.
                                                                                    –4
                                                                                    Товарищ что вы курите?)))
                                                                                    В моем объекте через геттер можно вытащить ТОЛЬКО значение, но ИЗМЕНИТЬ объект (состояние) нельзя.
                                                                                    Вывод — нет в вашем мозге способностей программировать на php.
                                                                                    +1
                                                                                    вы глупы
                                                                                    да автор, вы настолько не опытны
                                                                                    Автору желаю скорейшего просветления
                                                                                    Для вас специально дополню
                                                                                    Вы явно не читали документацию.
                                                                                    Статья вводит в заблуждение новичков.
                                                                                    3. Статья «ниочем»

                                                                                    Дружище, извините меня за все, чем доставил вам неудобство…
                                                                                    Отныне не намерен читать ваши ответы и комментарии, вас не понимаю абсолютно, не намерен слушать ваши комментарии по части доки и прочих, тк повторюсь — тут обсуждение идет не работы Доктрины и Симфони. Остановитесь, дружище.

                                                                                      –3
                                                                                      тут обсуждение идет не работы Доктрины и Симфони

                                                                                      У вас название статьи «проблемы с инкапсуляцией в Symfony проектах»
                                                                                      А тело статьи относится к доктрине :)
                                                                                      Извиняю вас — вы и сами скоро поймете все, а то
                                                                                      Сравнительно недавно работаю с Symfony (чуть более года)

                                                                                      это слишком мало чтобы разобраться на 100% в исходниках symfony и doctrine2
                                                                                        +1
                                                                                        У вас название статьи «проблемы с инкапсуляцией в Symfony проектах» А тело статьи относится к доктрине :)

                                                                                        А не потому ли, что подавляющее большинство проектов на Symfony используют Doctrine в качестве ORM?

                                                                                          –3
                                                                                          Браво — ваш вопрос еще один косяк статьи отражает.
                                                                                          Большинство могут использовать doctrine2 вне проектов на symfony.
                                                                                          Но проблема будет относится к symfony )))
                                                                                          Угомонитесь статьи-написаторы, вы сначала программировать научитесь, а потом уже статьи пишете, а не наоборот.
                                                                                            +2
                                                                                            Ты втираешь мне какую-то дичь

                                                                                            Ну, а если серьезно, не поделитесь ли вы своим опытом? Просто стебаться и советовать «научиться программировать» — это, конечно весело, но бесполезно.

                                                                                  0

                                                                                  Э, что из того, что вы написали в коде противоречит моим словам? Сеттеров у вас вообще нет, а геттеры дают гарантии ожидаемых типов.

                                                                                    –1

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

                                                                                      +1

                                                                                      Причём тут возможно или нет. Ваш код подверждает мои слова, что есть некая очень распространённая ментальная модель, по которой у для каждого геттера/сеттера есть однименноё внутренне свойство у объекта. Она настолько распространена, что не то что в IDE, а даже в языки вводится её поддержка, хотя по факту это раскрытие данных о внутреннем устройстве объекта. И если с геттерами ещё не сильно удивишься, встретив не return $this->prop, то от для сеттеров как миниум ожидается исполнение контракта:


                                                                                      $obj->setProp(1);
                                                                                      assert($obj->getProp() === 1);
                                                                                        –2

                                                                                        Это не модель, вы геттер и сеттер можете называть как угодно. Причём тут название методов?
                                                                                        setProp, может выставить вам что угодно, вы не знайте и не должны знать что внутри есть такое свойство. getProp аналогично. Название метода просто подсказка как работать с объектом. Если у объекта есть setStatus принимающий int, это не значит что внутри обьекта он выставит свойство status, он может делать там что угодно — вас это не должно касаться. Вам дали интерфейс доступа — причем тут внутр. свойства объекта?

                                                                                          +1
                                                                                          Она настолько распространена, что не то что в IDE, а даже в языки вводится её поддержка
                                                                                            –3
                                                                                            а вы спросите у JetBrains почему они реализовали в своих IDE функцию Code->Generate->Getter/Setters и он генерит по свойствам: не потому ли что очевидная реализация сгенерить методы по названиям свойство?!
                                                                                            Или вы предлагайте генерить рандмоные названия методов?
                                                                                            Откуда такое мнение я вообще не могу понять. Нигде нету пруфа что это именно сделано ради того что «распространено».
                                                                                              +2
                                                                                              Или вы предлагайте генерить рандмоные названия методов?

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

                                                                                              Вы можете перечитать тему (простив изначально наличие слова Symfony в заголовке) — она именно об этих вещах.
                                                                                                0
                                                                                                не потому ли что очевидная реализация сгенерить методы по названиям свойство?!

                                                                                                Именно, очевидная, настолько очевидная, что она и в обратную сторону действует: подавляющее большинство разработчиков увидев методы get/setName будут уверены, что там внутри есть свойство $name, которое отдаётся геттером напрямую, ну а в сеттере могут быть проверки типа на пустую строку. И в подавляющем большинстве случаев они будут правы. Ещё иногда будет что-то вроде return $this->data['name'] в getName()

                                                                                              +4
                                                                                              Если у объекта есть setStatus принимающий int, это не значит что внутри обьекта он выставит свойство status, он может делать там что угодно — вас это не должно касаться. Вам дали интерфейс доступа — причем тут внутр. свойства объекта?

                                                                                              Сеттеры/геттеры в рамках статьи рассматриваются исключительно как именно те, которые просто ставят, просто достают, то есть имитируют public свойство.
                                                                                              Такая практика, а именно жесткое ограничение сеттеров/геттеров только вышеописанным поведением, распространена, что и явилось причиной написания этой статьи.
                                                                                                –4
                                                                                                1. В вашей «статье» нет слов «имитируют», «public свойство» и т.п.
                                                                                                2. Покажите мне пруф где описано в документациях к doctrine2 или к symfony что «такая практика, а именно жесткое ограничение сеттеров/геттеров только вышеописанным поведением, распространена», откуда вы это взяли?! Из своего горького опыта?!
                                                                                                В вашей статье нет ничего из вашего комментария выше.
                                                                                                Даже по словам предыдущего комментатора нигде нету на это намека.
                                                                                                Название статьи и ее содержание не соответствуют вашему комментарию.

                                                                                                В статье вы подводите итог: «Код с сеттерами/геттерами заметно усложняет код, со сложным доменом и так бывает не просто...». — простите что усложняет код, я вам привел пример UserOrder, что там осложняется то?

                                                                                                Все это оборачивается тем, что детали бизнес-логики приходится изучать в посторонних строках кода.

                                                                                                Внезапно. А вы хотили God Object — простыню в которой и работа с данными и валидация, и UI… Ах да это все виновата практика getter/setter когда IDE генерят методы автоматом.

                                                                                                Что же такое инкапсуляция? Под инкапсуляцией обычно понимают сокрытие данных, поведения, деталей и условий. Когда мы раскрываем детали

                                                                                                Вы вроде бы пишите что это сокрытие, а потом пытайтесь раскрывать. Где тут речь про «распространненную практику» ?!

                                                                                                Далее ваш пример с Order — у вас даже методы разные в нем но вы их сравнивайте, один с getterом, другой без него где есть deliver метод. Это разные логические сущности. Вы думайте active record паттерном а не ORM.
                                                                                                Тут в комментах многие писали вам про это, что у вас просто нет понимание для чего нужен ORM. И да это распространненая практика, потому что это ORM и это doctrine. И внезапно это конструкции языка без которых невозможно сделать что либо: )

                                                                                                При этом вы считайте что если Вася написал невалидный объект с невалидными сеттерами и контролем состояния, то это «проблема с инкапсуляцией в symfony проектах».

                                                                                                Удалите статью пожалуйста, не позорьтесь.

                                                                                                  +2
                                                                                                  тяжелый случай :)
                                                                                                    +2
                                                                                                    Вы думайте active record паттерном а не ORM

                                                                                                    Это в вашей больной фантазии, в моих примерах ТОЛЬКО про инкапсуляуию бизнес-логики и БАНАЛЬНЕЙШЕЕ ООП

                                                                                                    Active Record — это про хранение данных в БД, точнее умение модели это делать и о диком нарушении SRP. Где вы в посте увидели намеки на него, когда речь идет о бизнес-слое и бизнес-логике — остается только догадываться и призывать священника, чтобы объяснил эти дъявольские наречия ваших мыслей :)



                                                                                                    К сожалению у вас нет понимания, как работает и Маппер, зачем он нужен и его роль, и даже что такое инкапсуляция вы не понимаете. Буквоедство вам простим :)
                                                                                                      –3
                                                                                                      не знаю что такое «Маппер», погуглил не понял о чем вы.
                                                                                                      Знаю только ORM, Маппер — это наверное из OSM тот кто карты вносит в БД, разве нет?
                                                                                                      Active Record — не понял причем тут хранение. База данных хранит данные, а не active record. Модель не может хранить данные, модель только умеет получать к ним доступ.
                                                                                                      Бизнес слой и бизнес логика — ага, и слово инкапсуляция, тоже очень совместимы.
                                                                                                        +3

                                                                                                        DataMapper — нет, не слышали?

                                                                                                          –2
                                                                                                          Причем тут DataMapper.
                                                                                                          ORM — это техника
                                                                                                          DataMapper — это шаблон.
                                                                                                          Учитесь дальше. Изучайте что такое ORM и для чего он нужен.
                                                                                                          ru.wikipedia.org/wiki/ORM
                                                                                                          и посмотрите что ActiveRecord входит в список библиотек ORM, и непосредственно относится к реализации ORM техники.
                                                                                                          Если автор даже не может понять что такое ActiveRecord, как он может учить других?!
                                                                                                            +1

                                                                                                            ORM — это техника, да. ActiveRecord и DataMapper — самые популярные шаблоны реализации этой техники. Doctrine как ORM библиотека реализует DataMapper, Eloquent как ORM библиотека — ActiveRecord

                                                                                                      +2
                                                                                                      В статье вы подводите итог: «Код с сеттерами/геттерами заметно усложняет код, со сложным доменом и так бывает не просто...». — простите что усложняет код, я вам привел пример UserOrder, что там осложняется то?

                                                                                                      У вас как раз не тот подход, который критикуется в статье — у вас нет сеттера.


                                                                                                      И да это распространненая практика, потому что это ORM и это doctrine.

                                                                                                      Распространённая практика в Symfony+Doctrine проектах делать в сущностях пару сеттер/геттер на каждое поле, маппящееся на базу, чуть ли не автоматом (вроде даже генератор штатный так и делает). Автор Doctrine с этим подходом не согласен, кстати.


                                                                                                      Внезапно. А вы хотили God Object

                                                                                                      God Object получается если в класс сущности с геттерами/сеттерами добавить бизнес-логику. Если не добавлять, то язык не поворачивается называть это сущностью обычно, просто DTO какой-то. Эта статья про то, что лучше хотя бы сеттеры убрать, чем смешивать геттеры/сеттеры и бизнес-логику в одном классе.

                                                                                                      –4
                                                                                                      И еще чтобы показать вам вашу глупость, вы даже не подумали «как я могу улучшить код», вместо этого вы осуждайте его.
                                                                                                      Ниже приведу код, который уже поражен проблемами, которые появились из-за возможности нам «удобно» читать поля

                                                                                                      Посмотрите на код. Его легко привести в зависимость от объекта, просто убрав логику в сервис. К тому же doctrine2 регламентирует использование репозиториев, а вам нужно еще управлять UI. Заказ не найден — это бизнес логика. Поэтому ничего в этом страшного нет.
                                                                                                      $order = $this->orderRepository->find($orderId); 
                                                                                                      if(empty($order)) { $this->createNotFoundException(); }
                                                                                                      if ($order->canHandled()) {
                                                                                                       //тут можно даже указать объекту что он вошел в состояние обработки
                                                                                                        $this->orderDeliveryService->handle($order);  //или тут
                                                                                                      }
                                                                                                      

                                                                                                      К тому же вы не рассматривайте сложный случай, когда у вас будут независимые от заказа объекты и логика с ними, элементарно вам понадобится транзакция. И тогда вам нужно делать так:
                                                                                                      $order = $this->orderRepository->find($orderId); 
                                                                                                      if(empty($order)) { $this->createNotFoundException(); }
                                                                                                      $this->orderRepositroy->beginTransaction();
                                                                                                      $log = new SystemLog("new order");
                                                                                                      try {
                                                                                                      if ($order->canHandled()) {
                                                                                                       //тут можно даже указать объекту что он вошел в состояние обработки
                                                                                                        $this->orderDeliveryService->handle($order);  //внутри состояние модифицруется но мы раскроем его здесь
                                                                                                       //код реалзиации handle
                                                                                                       $order->makeOrderDelivered(); //аналог $order->setStatus(Order::STATUS_DELIVERED)
                                                                                                        $this->getOuterCustomerService()->log($log); //например внешний сервис который может не работать
                                                                                                        $this->orderRepository->commit();
                                                                                                       return $order; //Тут вам уже доступен объект с другим status - бизнес проверка состояния -> $order->isDelivered() или $order->getStatus() более глубокая проверка состояния для других нужд 
                                                                                                      } 
                                                                                                      } catch(\Exception $e) {
                                                                                                       $this->orderRepository->rollback();
                                                                                                      }
                                                                                                      


                                                                                                      Оперирование объектом удобнее, во всех планах.
                                                                                                      Если вам не нравятся сеттеры/геттеры, то вас никто не принуждает их делать, нет такого требования в документациях. Вы определяйте public свойства в своем Order. Тогда код выше изменится на $order->status = Order::STATUS_DELIVERED. Но тем самым вы даете возможность любому сервису в любом месте, даже внутри repositroy->find изменить ваш объект.

                                                                                                      В вашей статье возьмем за валидный пример Order без геттеров и сеттеров который реализует логику deliver, эта логика может зависеть от внешних не обязательных факторов. Тогда вам не возможно будет обойтись без модификации объекта управляющим кодом, то есть менеджером или сервисом.

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

                                                                                                        Речь о том, что не должно быть в коде, претнедующем на качество ни


                                                                                                         $order->status = Order::STATUS_DELIVERED;

                                                                                                        ни


                                                                                                        $order->setStatus(Order::STATUS_DELIVERED);

                                                                                                        должно быть только что-то вроде вашего $order->makeOrderDelivered()


                                                                                                        Я вот не пойму, вы с Maksclub говорите об одном и том же, просто не понимаете этого, или где-то кардинальные различия?

                                                                                                          +1
                                                                                                          мы не говорим, тут идет монолог с обвинениями :)
                                                                                                            –4
                                                                                                            По каким таким стандартам оценивайте «качество»?
                                                                                                            Почему название метода влияет на качество?
                                                                                                            Почему должно быть «ТОЛЬКО».
                                                                                                            С чего такие ограничения?
                                                                                                            Вы опять решили за всех и ввели свой стандарт качества, ничем не аргументированный и нигде не подтвержденный.
                                                                                                              +2
                                                                                                              Почему мы должны читать и слушать вас? :)
                                                                                                                +3
                                                                                                                Автор видимо придется мне опубликовать рецензию на вашу статью.
                                                                                                                  0
                                                                                                                  Опубликуйте, было бы интересно! Серьезно, без троллинга.
                                                                                      +1
                                                                                      Здравствуйте. Спасибо за хорошую статью!
                                                                                      Мне кажется, в первом примере проверка deliveryDate является лишней в контексте того, что мы изменяем это поле только в методе deliver.
                                                                                      А если объект оказывается в несогласованном состоянии (через рефлексию или данные в БД испорчены), то видимо правильней бросить исключение.
                                                                                        0
                                                                                        спасибо, пример чисто академический — именно для примера:
                                                                                        связать некие данные и инкапсулировать в одном методе (этих методов может быть больше конечно)
                                                                                        0
                                                                                        Окей, вы говорите, что сущности — это не тупые DTO и должны экспоузить наружу не просто геттеры и сеттеры, а методы, реализующие бизнес-логику и бизнес-правила. То есть быть умнее. Как быть с зависимостями? Например, представим, что Order::deliver() в вашем примере должен сходить ещё в какой-то сервис, что-то там проверить перед установкой статуса и/или отправить какое-нибудь уведомление после установки статуса. Как это реализовать, учитывая, что DI Symfony не даст вам воткнуть зависимость в сущность?
                                                                                          +3

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

                                                                                            0
                                                                                            Тогда получается, что Order::deliver() всё ещё инкапсулирует не всю необходимую логику, часть её всё ещё лежит в каком-то стороннем сервисе. И другой сервис всё ещё может вызывать напрямую Order::deliver() в обход первого сервиса. Это чуть лучше чем тупые сеттеры/геттеры, но всё ещё недостаточно хорошо. Принципиальная проблема инкапсуляции всей логики на уровне сущностей не решена.
                                                                                              +2

                                                                                              Не стоит задачи инкапсулирования всей логики на уровне сущностей. Сущность инкапсулирует только то, что касается только её. Может эмитирует события наружу, но не более. В идеальном DDD мире :)

                                                                                                0
                                                                                                Тут вижу две проблемы:

                                                                                                1) Задача инкапсулирования всей логики всё равно стоит. И если вы (или DDD) предлагаете её решать не на уровне сущности, то где? На уровне сервисов? Тогда как защититься от того, что API сущности позволяет разным сервисам по-разному с ней работать? Это очень напоминает исходную ситуацию, когда в сущности только тупые геттеры и сеттеры, и мы защищаемся от бездумного дёргания этих методов лишь тем, что договариваемся, мол, с этой сущностью можно работать только через такой-то и такой-то сервис. То есть, эта защита на уровне договорённостей, а не языка. Понятно проблему сформулировал? Что нам говорит DDD делать в таких ситуациях?

                                                                                                2) Сущность User хочет инкапсулировать в себе генерацию пароля. Ей для этого нужен сервис, который генерит рандомные строчки. О том, что он ей нужен, знает только сама сущность, это деталь её реализации, и внешний код, который использует этот метод, по-хорошему не должен догадываться о том, что сущность использует этот сервис. DI Symfony не даст нам нормально воткнуть в сущность эту зависимость. Да и DDD говорит, что зависимости в сущностях — это атата. Как быть?
                                                                                                  +3

                                                                                                  1) Полноценная сущность надёжно контролирует свои внутренности на своём уровне. Оркестрацией сущностей занимается внешний сервис-юзкейс. В отличие от имения набора сеттеров в сущности, с которыми другой внешний сервис может её испортить, забыв присвоить какое-нибудь поле.


                                                                                                  2) Спокойно используется передача зависимостей в метод. Приходится протаскивать. Не синглтоны же в методе дёргать. Вместо передачи в конструктор, с которой у сущности как раз будет атата. У сущности не должно быть циклических зависимостей от внешних прикладных сервисов. А на своём доменном уровне может дёргать кого угодно.

                                                                                                    0
                                                                                                    1) Полноценная сущность надёжно контролирует свои внутренности на своём уровне. Оркестрацией сущностей занимается внешний сервис-юзкейс. В отличие от имения набора сеттеров в сущности, с которыми другой внешний сервис может её испортить, забыв присвоить какое-нибудь поле.

                                                                                                    Ну да, лазеек для поломки сущности как будто бы становится сильно меньше. Но всё ещё остаются, если мы не можем передать нужные зависимости в метод. Если же можем, то, кажется, что API сущности становится полным и при этом единственным местом для работы с сущностью. Годится.

                                                                                                    Не синглтоны же в методе дёргать.

                                                                                                    Смотря что понимать под синглтонами в данном случае. Внешний код, которому придётся передать эту зависимость в метод, всё равно получит её из DI-контейнера, и она фактически будет точно таким же синглтоном (в том смысле, что это один и тот же инстанс на всё приложение). Если внешний код может получить эту зависимость из какого-то общего контекста (DI-контейнера), то почему мы не хотим, чтобы модель могла сама её получить оттуда же?
                                                                                                      0
                                                                                                      то почему мы не хотим, чтобы модель могла сама её получить оттуда же?

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


                                                                                                      Есть ещё варианты, например использовать AOP через аннотации, который подменяет сигнатуру методов, добавляя ещё один параметр, значение которого берётся из DI — но это дорого в плане ресурсов и/или дев-флоу.

                                                                                                        0
                                                                                                        Я использую SL в конструкторе и там же делаю проверку на тип сервиса. Получается почти то же самое, что и настоящий конструктор, только с зависимосью от SL
                                                                                                        class Order {
                                                                                                        
                                                                                                            private $dep;
                                                                                                            
                                                                                                            public function __construct()
                                                                                                           {
                                                                                                               $this->dep = ServiceLocator::instance()->get(Dependency::class);
                                                                                                               \webmozart\Assert::isInstanceOf(Dependency::class, $dep);
                                                                                                           }
                                                                                                        
                                                                                                        }
                                                                                                        
                                                                                                        
                                                                                                          +1
                                                                                                          Получается почти то же самое, что и настоящий конструктор, только с зависимосью от SL


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

                                                                                                          И ещё — вы покрываете unit-тестами эти классы Мокаете все зависимости?
                                                                                                            0
                                                                                                            Да мокаю, здесь проблемы нет. Просто в setUp() локатор пересоздаю и нужные для теста моки туда добавляю. Можно и сам локатор замокать, с этим тоже проблем нет, но эта штука крайне простая, поэтому добавляю в него моки сервисов.
                                                                                                              0
                                                                                                              Получается утеря над контролем зависимостей, новые виды и пути для возникновения ошибок.

                                                                                                              А можете более подробно разъяснить, в чем именно заключается утеря?
                                                                                                              Какие вы видите новые пути для возникновения ошибок?
                                                                                                      +1

                                                                                                      1) Состояние хранится в сущностях, логика работы с ним размазывается по сущностям и доменным сервисам (VO, репозитории и т. д. опустим для краткости). В отличии от тупых сеттеров мутирующие состояние бизнес-методы сущности дают гарантии, что состояние сущности всегда соответствует бизнес-правилам, значения свойств согласовано. Работать с сущностью может любой сервис по умолчанию, гарантии даются на уровне кода. Средства языка бизнес-гарантии не дают.


                                                                                                      2) "Кто ж его посадит, он же памятник" В смысле мало ли что сущность хочет :)
                                                                                                      Если серьёзно, то DDD-подходы это не серебряная пуля, по умолчанию обычно подобные зависимости инжектятся через параметр нужного метода через интерфейс, $user->generateNewPassword(IPasswordGenerator $generatorPassword). То есть с точки зрения сущности полностью на уровне непосредственного клиента конфигурируются. Он их, конечно, может получать из DIC, если сам сущностью не является. А, в принципе, как раз пароль один из хороших практических примеров, когда тупые сеттеры имеют право на жизнь — клиент и сам может генератор дернуть.

                                                                                                        0
                                                                                                        $user->generateNewPassword(IPasswordGenerator $generatorPassword)

                                                                                                        Вроде рассуждаете много правильно, но в нескольких местах даёте вредные советы, по-моему. Тут нарушение слоистой архитектуры.
                                                                                                        Книжка Эванса о DDD в основном о том, что такое ubiquitous language, как важно выделять бизнес сценарии, выделять границы доменов, события события, имеющие смысл для бизнеса и так далее.
                                                                                                        Что тут получается, юзер генерирует свой пароль на сайте, это правильное описание? Тогда либо внешняя зависимость не нужна, либо это ответственность уровня приложения. Нет ничего плохого в логике на уровне приложения.
                                                                                                        Вообще есть совет, не знаю насколько удачный, начинать с логики на сервисном уровне и потом переносить её на уровень домена, то, что связано с логикой изменения состояния агрегата.
                                                                                                          0
                                                                                                          А так лучше? $user->generateNewPassword(), зависимость уже внутри?
                                                                                                            0
                                                                                                            Если пользователь знает как генерировать пароль, то нормально. Зависимость тут не нужна. Если этот метод по сути кусок application layer, засунутый внутрь бизнес-сущности, то это против стандартных рекомендаций разработки.
                                                                                                            0

                                                                                                            Я тут конкретную задачу рассматривал — как передать зависимость в сущность абстрагируясь до юзера и пароля. И, приведя пример, увидел, что лучше как раз тут просто сеттер для пароля сделать, о чём тут же и написал.

                                                                                                              +1
                                                                                                              Вроде рассуждаете много правильно, но в нескольких местах даёте вредные советы, по-моему. Тут нарушение слоистой архитектуры.
                                                                                                              Книжка Эванса о DDD в основном о том, что такое ubiquitous language, как важно выделять бизнес сценарии, выделять границы доменов, события события, имеющие смысл для бизнеса и так далее.


                                                                                                              В той же книги (или у Вернона, я уже не помню) приводится пример что репозиторий это доменный объект, но его имплементация это persistence. То же самое и с примером выше, с чего вы взяли что IPasswordGenerator это другой слой? Это объект домена User, котрый генерит свой пароль, именно User контролирует инварианты, когда его генерить и в каком сосотянии (например при регистрации). А уже имплементация IPasswordGenerator это уже не дело User, и он ничего об этом другом «слое» не знает, консумер `generateNewPassword` только знает и передает ту имплементацию какую хочет.
                                                                                                            +3
                                                                                                            1) Конкретно всю логику сущность и не должна инкапсулировать. При $order->deliver() меняется внутреннее состояние самого $order, ему неважно что нужно юзеру смс отправить или баллы бонусные посчитать. При этом $order может возвращать связанные с ним события при вызове какого-то emitNewEvents(), которые родительский сервис может диспатчить или не диспатчить. Если речь о том что в любом месте кода можно достать $order и вызвать deliver(), то с этим ничего не сделаешь, тут тысячи способов сломать стейт, рефлексия, апдейт напрямую через pdo и т.п. Если бы в пхп можно было разбивать код на модули и делать приватны для модуля классы то может быть.

                                                                                                            2) Генерация пароля это отличный кандидат на свой отдельный класс/сервис. Много вопросов как раз из-за того что это не обязанность юзера их генерить, а делать метод внутри юзера, который принимает сервис и делает что-то вроде $this->password = $service->generate() ничем не лучше обычного сеттера. Для безопасности сеттеров можно как раз использовать Value Objects, например GeneratedPassword.
                                                                                                              0
                                                                                                              что это не обязанность юзера их генерить

                                                                                                              На основании чего так решили?
                                                                                                                0

                                                                                                                А на основании чего решили, что это его обязанность?

                                                                                                                  0
                                                                                                                  А я еще ничего не решил, просто уточняю.
                                                                                                                  +2
                                                                                                                  На основании чего так решили

                                                                                                                  На основании того что работы со стейтом объекта Order не происходит. Order вообще может не хранить email пользователя. Суть всей затеи в том чтобы инкапсулировать работу с состоянием.


                                                                                                                  Координация действий (доставить order => отправить email) может быть спокойно вынесена в сервисы, т.к. если в них нет ветвлений нет нужды покрывать их юнит тестами.
                                                                                                                  Альтернатива — ивенты. Меньше контроля(вся координация уже не в одном месте), но ниже связность системы.

                                                                                                                    0
                                                                                                                    Так речь не об Order, а о User и генерировании пароля. А так согласен, в ООП одним из критериев распределения поведения является использование в этом поведении стейта, грубо говоря первым какндидатом на поведение будет класс, у котого есть стейт, с которым работает это поведение.
                                                                                                                      0
                                                                                                                      Order вообще может не хранить email пользователя. Суть всей затеи в том чтобы инкапсулировать работу с состоянием.


                                                                                                                      Суть в том что Order имеет Customer и бизнес правило утвреждает что «при доставке Order нужно сообщить клиенту» или перефразировав «ордер при смене состоянии на доставленный должен сообщить клиенту».
                                                                                                                    0
                                                                                                                    При $order->deliver() меняется внутреннее состояние самого $order, ему неважно что нужно юзеру смс отправить или баллы бонусные посчитать.


                                                                                                                    Почему не важно? Если домен Order требует чтоб при смене состояния заказа на «отправленный» дать знать клиенту или посчитать бонусные балы клиента?
                                                                                                                      +2

                                                                                                                      Баллы может считать и Customer, хотя попахивает, но вот отправлять сообщения точно отвественность ни Order, ни Customer. Order или DeliveryService эмитят событие типа OrderDeliveredToCustomer($orderId, $customerId), а какой-то CustomerNotificationService подписывается на него и при наступлении как-то уведомляет клиента (или персонал, что не получилось уведомить)

                                                                                                                        +1

                                                                                                                        Бонусы наверняка тоже лучше в отдельную сущность вынести, т.к. логика там может быть самая разнообразная)

                                                                                                                          +2

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

                                                                                                                          0
                                                                                                                          А я и не говорил что именно Order считает бонусы, это может делать и Customer и бонусы могут быть отдельным классом и много чего может быть, сложно дезайнить классы не знаю требования и домен. И да, ивентытоже могут быть использованы если они используются в архитектуре. Вы не уловили мысль, скорее всего это моя вина, я не правильно выразился. Идея в том что Order ответственен при своей смене запустить процесс начисления бонусов, будь то вызов поведения Customer либо записать ивент и сделать это асинхронно. Это не дело какого-то там «Application Service»? Это логика домена.

                                                                                                                          Я считаю смысл «Application Service» в настоящее время не отражает изначальный смысл этого термина. Например возьмем историческую работу Жефри Палермо jeffreypalermo.com/2008/07/the-onion-architecture-part-1
                                                                                                                          В ней если разобраться Application layer и Application services это что-то очень общее для кординирования приложения в целом: это SessionManager, AuthenticationManager, CommandBus. Это не сервисы которые содержат бизнес логику, знаний как реагировать на смену ордера, нужно ли начислать бонусы или нет, отправлять письмо по смене заказа или нет, и тд. Все эти классы с одним методом «handle», часто встречающиеся в настоящее время, даже ООП нельзя назвать, это обычные функции и от объектов там нет ничего.
                                                                                                                            0

                                                                                                                            Вот я не считаю, что класс Order должен быть ответственен за начисление бонусов при смене статуса на "доставлен". Он ответственен, в "худшем" для него случае, за оповещение остального домена о смене статуса. А какой-нибудь сервис посчитает бонусы как реакцию на это событие, а то и как реакцию на отсутствие ошибки. Сервис доменного уровня, Domain Service, а не Application Service. Вот здесь поверхностно описано https://enterprisecraftsmanship.com/posts/domain-vs-application-services/


                                                                                                                            На практике часты разные мнения о том как именно (скорее на каком уровне) связывать событие типа смены статуса заказа и запуск процесса начисления бонусов. Я часто это делаю на уровне Application Service из соображений практичности, что не создавать отдельный Domain Service для подобных кейсов пока их мало.

                                                                                                              0

                                                                                                              Передать зависимость в метод и там сгенерировать событие для отправки уведомления.

                                                                                                                0
                                                                                                                Принимается. Технически это действительно сработает в большом количестве случаев.

                                                                                                                Вижу два неприятных момента:

                                                                                                                1) Symfony DI тут никак не поможет — зависимости придётся передавать явно. В частности, если у нас есть стек вызовов таких умных методов, и самому глубокому из этих методов понадобилась какая-то зависимость, её придётся пробрасывать через весь стек, не получится просто взять её из контейнера на нужном уровне.

                                                                                                                2) Циклические зависимости. Слой сущностей начинает зависеть от слоя сервисов, который, в свою очередь, зависит от слоя сущностей. Это, как минимум, неаккуратно (и идёт в разрез, например, с чистой архитектурой Фаулера, да и DDD тоже).

                                                                                                                Есть идеи, как преодолеть эти две неприятности?

                                                                                                                  0

                                                                                                                  2) Слой сервисов — абстракции

                                                                                                                    0
                                                                                                                    А можете подробнее? Непонятно, что именно имеете в виду и как это решает заявленную проблему.
                                                                                                                      +1

                                                                                                                      1) Да, передаём внешнему методу весь комплект. Нам снаружи всё равно, сам он будет дело делать или приватным методам делегировать.


                                                                                                                      2) Например, метод сущности принимает интерфейс, лежащий рядом с сущностью.

                                                                                                                        +1
                                                                                                                        1) Я в соседней ветке привёл пример, когда это выглядит не очень. Сущность User хочет генерить пароль для пользователя, и ей для этого нужен сервис, генерящий рандомные строки. Использование этого сервиса — это настолько внутренняя деталь реализации, что обязывать код, вызывающий метод генерации пароля, знать об этой детали и инстанциировать нужную зависимость, чтобы передать её в метод, кажется прям совсем грязным решением. Но, честно говоря, это выглядит не как проблема DI в целом, а как проблема конкретных реализаций этого паттерна (в частности, реализации в Symfony). Хотя, с другой стороны, DDD-ребята вроде как идеологически против зависимостей от сервисов в сущностях. Но тогда я не понимаю, как предлагается красиво решать описанную проблему.

                                                                                                                        2) Ага, это Dependency Inversion из SOLID. Принимается.
                                                                                                                          0

                                                                                                                          2) угу, в рантайме по факту циклическая зависимость есть, но на уровне "компайл-тайма" сущность и сервис начинают зависеть от одной абстракции

                                                                                                                            0
                                                                                                                            Ага, это Dependency Inversion из SOLID. Принимается.
                                                                                                                            Inversion Of Control параллелен обсуждаемой «слоистой» архитектуре. Он может быть и при полном отсутствии слоёв. Это два независимых метода борьбы со сложностью.
                                                                                                                            Как насчет принципиального отсутствия побочных эффектов у доменного слоя, к примеру? Идея ведь сделать доменный слой «конечным», а не пробрасывать через домен вызовы обратно к внешним слоям.
                                                                                                                            В доменный слой можно передать интерфейс репозитория, да любой внешний интерфейс. Вон выше один пользователь Event Bus предлагает передавать, тоже через интерфейс. Пароль, к примеру, и микросервис ведь может генерировать. А потом доменный объект пишет в Event Bus событие о том, что пароль сгенерирован. Всё это неприкрытая коммуникация домена и приложения с инфраструктурой. Работать это будет, но сопровождение из-за запутанной графовой структуры приложения, вероятно, будет не таким простым.
                                                                                                                              0
                                                                                                                              Добавлю еще, что в большинстве случаев никакой бизнес-логики собственно у сущностей и нет, и речь идёт о простейшем BREAD (CRUD). Если так, то лучше оставить такую анемичную сущность, чем делать её прокси к вышележащим слоям. BREAD — это нормально, если никаких инвариантов действительно нет. Заодно сразу видно, что их нет и куда и как добавить.
                                                                                                                      0
                                                                                                                      Symfony DI тут никак не поможет — зависимости придётся передавать явно. В частности, если у нас есть стек вызовов таких умных методов, и самому глубокому из этих методов понадобилась какая-то зависимость, её придётся пробрасывать через весь стек, не получится просто взять её из контейнера на нужном уровне.

                                                                                                                      Мне кажется, что появление "сквозной" зависимости говорит о том, что что-то пошло не так...

                                                                                                                    0
                                                                                                                    Во во, я тоже очень много об этом говорил, в т.ч. в комментах на хабре. Даже смешно, когда народ удивляется, что это во многих doctrine-проектах анемичные сущности. Без зависимостей полноценную логику туда не положить, вот и получаются классы с одними геттерами/сеттерами. Кто об этом знает, начинает выходить из положения путем чего-то вроде Order::deliver(Dependecy $dependency), но иногда (не всегда) это то же своего рода раскрытие деталей, нарушение инкапсуляции. Когда у нас есть объект заказа, нас не должно волновать, что он там и как будет проверять, заказ должен знать все о таких проверках сам, тогда будет инкапсуляция.
                                                                                                                      +1

                                                                                                                      А что считать полноценной логикой, а что неполноценной?


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