Внедрение предметно-ориентированного проектирования в PHP

Совершенно верно. Большие контексты плохо и совсем маленькие контексты тоже плохо. Нужно искать золотую середину. Моя золотая середина это два отдельных контекста комментарии и страницы. Ваша золотая середина это комментарии и страницы в одном контексте. Я уже устал это повторять. Давайте завязывать.

Внедрение предметно-ориентированного проектирования в PHP

но всё равно нужно записать это в базу в пределах одной транзакции с получением результата запроса.

Ещё раз. Почему в пределах именно одной транзакции? Почему нельзя обработать запрос в фоне?

Даже если вы не используете Commad и Query, а используете методы, то почему метод в духе getPage() должен ещё и писать что-то? Кидать событие, да возможно, но не писать.

Внедрение предметно-ориентированного проектирования в PHP

Вы ввели понятие "комментатор" сильно позже.

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

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

Ну во первых, сущность комментариев не такая уж и "мало-мальски значащая". Мы сейчас общаемся на Хабре в комментариях и я, обсуждая комментарии, ассоциирую их с комментариями Хабра, а комментарии на Хабре не такие уж и мало значащие.
Во вторых, да. Контексты должны быть маленькими. Чем меньше контексты, тем они оптимальней. Большие контексты сродни отсутствию контекстов вообще. Если мне память не изменяет, то именно Вернон говорил об этом в своей книге. Рекомендую почитать если вы ещё не читали.

Внедрение предметно-ориентированного проектирования в PHP

Разве? Вроде и по Ubiquitous Language прошлись. Напоминаю:

• User — в контексте страниц пользователь является автором страниц;
• User — в контексте комментариев к страницам пользователь является комментатором.

Можем ещё модераторов добавить.

• User — модератор страниц;
• User — модератор комментариев;
• Модератор страниц может подтвердить или отклонить публикацию страницы;
• Модератор комментариев может удалить или заблокировать комментарий.

Можем ещё пробежаться по Use cases страниц и комментариев.

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

Внедрение предметно-ориентированного проектирования в PHP

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

Обновлять щетчики просмотров можно 2 способами. Можно на fronend через js или картинки по аналогии с другими метриками. Можно на backend кидать event "страница просмотрена".
Первый вариант предпочтительней так как в этом случае вы можете полностью или частично закешировать страницу и не дергать бекенд лишний раз. А щетчики на странице в этом случае обновлять через API.

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

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

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

Внедрение предметно-ориентированного проектирования в PHP

Такой подход работает лишь в сильно специализированных не CRUD приложениях.

Так в этом и смысл. Незачем городить DDD в CRUD приложениях.

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

Внедрение предметно-ориентированного проектирования в PHP

Страница вывода поста — обращение как минимум к «посты», «комментарии» и «пользователи», блок «Самые комментируемые посты» — обращение как минимум к контекстам «посты» и «комментарии».

Повторюсь. Это Read поток. Для оптимизации нагрузки рекомендуется не использовать домен на этом уровне (см. CQRS). Для оптимизации нагрузки все эти данные, как правило, кладутся в NoSQL хранилища или вытягиваются простыми запросами к БД и не строят многоуровневые агрегаты, а используются DTO или вообще массивы.

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

Это мнение Эванса и Вернона и я с ними солидарен. Я не хочу сказать, что все должны делать так, но там где есть выделенный домен, как правило задумываются о разделении read и write потоков.

Вот вопрос скорей стоял где та гран

Грань каждый определяет сам. Есть некоторые рекомендации описанные в книгах по DDD, но четких правил нет.

Внедрение предметно-ориентированного проектирования в PHP

Эванс и Вернон говорили о том, что поднимать весь домен на каждый запрос бессмысленно. Он нужен только для записи, а для представления стоит использовать DTO.

Внедрение предметно-ориентированного проектирования в PHP

Конечно же роли пользователя, а не свойства пользователя )))

Внедрение предметно-ориентированного проектирования в PHP

Нет, "также" остаётся. Ключевые слова "также является автором страниц и комментариев", а не про права.

Пунктуация страдает. Я иначе воспринял ваше предложение. Прошу прощения.
Вообще, с формулировкой можно много играться. Например:

User — человек, персонифицированный пользователь системы, прошедший аутентификацию, имеет набор прав на различные действия в системе, автор страниц, комментатор.

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

• User — человек;
• User — персонифицированный пользователь системы;
• User — пользователь прошедший аутентификацию;
• User — пользователь имеющий набор прав на различные действия в системе;
• User — автор страниц;
• User — комментатор.

Вспоминаем Фаулера

As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility — here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like "Customer" and "Product".

По поводу:

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

Учитывая то, о чем мы тут говорим, вопрос надо ставить так: Почему страница в контексте комментариев должна быть VO, представляющим сущность из другого контекста, а не сущностью в этом контексте?

Внедрение предметно-ориентированного проектирования в PHP

Я немного сплоховал. Должно быть CommentatorId, а не CommentAuthorId.

Внедрение предметно-ориентированного проектирования в PHP

У вас не совсем корректная формулировка

набор прав на различные действия в системе

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

имеет набор прав на различные действия в системе такие как создание страниц и их комментирование.

Вот уже и нет никаких "так же".
Вообще, права пользователя зависят от контекста и контекст определяет права пользователя, а не наоборот.
Например: read-only пользователь на Хабре не может голосовать за статью. Это ограничение диктуется контекстом статей, а от пользователя здесь только его тип.

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

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

Может комментарии и страницы нужно разделять, а может и нет. Все зависит от проекта. В контексте маленького бложика я бы их не разделял. В контексте Хабра я бы их выделил в отдельный контекст потому, что у комментариев много своей бизнес логики ни как не связанной со статьями. Собственно, вся связь ограничивается одной фразой из Ubiquitous Language — "прокомментировать статью".

Внедрение предметно-ориентированного проектирования в PHP

Собственно разделение на контексты надо производить когда в определениях терминов появляется «или», «а также», «с точки зрения», «в рамках» и т. п…

Если так рассуждать, то пол проекта может оказаться в одном контексте.
Например авторизация и аунтификация может оказаться в одном контексте с комментариями.

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

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

Так же ни кто не запрещает создавать комментарии в статье.

class Page
{
    public function comment(
        CommentAuthorId $author_id,
        CommentMessage $message
    ): Comment {
        $new_comment = Comment::comment(
            $this->id,
            $author_id,
            $message
        );
        $this->comments[] = $new_comment;

        return $new_comment;
    }
}

Внедрение предметно-ориентированного проектирования в PHP

Обсуждение было давно и я уже давненько не встречал маппинга в YAML.
А вот XML вполе используется, например в FOSUserBundle или SonataUserBundle.

Внедрение предметно-ориентированного проектирования в PHP

Вот как возникнут задачи «а давайте кроме страниц дадим возможность комментировать картинки», вот тогда и делить.

как я сказал ранее:

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

Контекст страниц и контекст комментариев к страницам находятся в одном контексте более высокого уровня.
То есть комментарии к странице это комментарии к странице и комментариями к картинкам они никогда не станут.
Разделять эти контексты или нет конечно дело каждого, но я вижу преимущества такого подхода.
Контекст из Ubiquitous Language можно организовать в независимый модуль в коде, который легко можно включать, отключать, переносить и изменять не затрагивая весь остальной проект и модуль страниц (контекст странц) в том числе.

А если нам понадобится комментарии к картинкам, то мы просто копируем модель комментариев к страницам и чуть-чуть дорабатываем напильником.
И так как в результате мы получим независимые модули мы можем изменять модуль коментирования картинок не затрагивая при этом модуль коментирования страниц.

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

Внедрение предметно-ориентированного проектирования в PHP

Боюсь не найду обсуждение((
По моему обсуждение было в личке в контексте CQRS.
Могу процитировать его мнение по поводу маппинга в аннотациях из нашей переписки:

Часто встречаю что правила хранения (маппинг) описываются в YML файле.

С одной стороны правильно не смешивать домен и правила его хранения, с другой стороны аннотации удобнее и читабильней yml конфигов. И аннотации проще поддерживать в актуальном состоянии.

это делается для того что бы ваши сущности не зависили от доктрины (у вас в коде нет use Doctrine\ORM\Mapping и все такое). Это единственная причина для этого. Все остальное — вкусавщина. Авторы доктрины например настоятельно рекомендуют хранить это добро в xml и только если вы планируете шарить сущности между проектами. В пределах одного проекта норм и аннотации.

Внедрение предметно-ориентированного проектирования в PHP

Почему бы не воспользоваться просто UUID-ом для генерации айдишки?

Можно и UUID. Кому как больше нравится. Но не стоит пренебрегать преимуществами естественных идентификаторов.

Аннотации от доктрины хоть и комменты, но все же часть инфраструктуры. При смене ОРМ-ки вы же их удалите? Или с какой целью они там лежат?

Можно и не удалять при смене ORM. Просто в этом случае они будут висеть мертвым грузом.
А можно мапинг описать не в аннотациях, а например в XML файле или в репозитории. От этого принципиально ничего не поменяется. Разница только в удобстве сопровождения.

Как вы соберете сущность, которая хранится в 2+ таблицах

В этом случае у нас связь OneToOne и связанная "сущность" это VO в агрегате. Эта "сущность" не будет иметь смысла вне агрегата как нормальный VO.

в разных хранилищах (к примеру каунтеры в редисе)

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

Я советую обратить ваше внимание на схему CQRS.
Реально поднимать домен нужно только на запись.

Хотя надо признать. Doctine накладывает ряд неприятных ограничений на структуру сущностей.

Внедрение предметно-ориентированного проектирования в PHP

На самом деле спорно, два это контекста или один

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

А ORM/… — протечка инфраструктуры в домен :)

нет, так как это только комментарии и в коде это не отражено)))
замена Doctrine на что-то еще ни как не повлияет на доменные сущности
в этом и суть переносимости домена

Внедрение предметно-ориентированного проектирования в PHP

Если говорить о DDD, то по хорошему страницы и комментарии это два разных Bounded Context и соответственно они не должны иметь связей.

По хорошему, сущность комментария должна иметь примерно такой вид:

Comment class

/**
 * @ORM\Table(name="comments")
 * @ORM\Entity
 */
class Comment
{
    // редактировать коментарий можно только 10 минут по аналогии с Хабром
    // константа публичная потому, что понадобится для валидации
    // на более высоких уровнях
    public const EDITING_PERIOD = '+10 minutes';

    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="NONE")
     * @ORM\Column(name="id", type="CommentId", nullable=false)
     *
     * @var CommentId
     */
    private $id;

    /**
     * @ORM\Column(name="page_id", type="PageId", nullable=false)
     *
     * @var PageId
     */
    private $page_id;

    /**
     * @ORM\Column(name="author_id", type="CommentAuthorId", nullable=false)
     *
     * @var CommentAuthorId
     */
    private $author_id;

    /**
     * @ORM\Column(name="reply_to_id", type="CommentId", nullable=true)
     *
     * @var CommentId|null
     */
    private $reply_to;

    /**
     * @ORM\Column(name="comment_at", type="DateTimeImmutable", nullable=false)
     *
     * @var \DateTimeImmutable
     */
    private $comment_at;

    /**
     * @ORM\Column(name="message", type="CommentMessage", nullable=false)
     *
     * @var CommentMessage
     */
    private $message;

    /**
     * @param PageId          $page_id
     * @param CommentAuthorId $author_id
     * @param CommentMessage  $message
     * @param CommentId|null  $reply_to
     */
    private function __construct(
        PageId $page_id,
        CommentAuthorId $author_id,
        CommentMessage $message,
        ?CommentId $reply_to = null
    ) {
        // конструктор приватный. создаем инстанс через фабрики

        $this->page_id = $page_id;
        $this->author_id = $author_id;
        $this->reply_to = $reply_to;
        $this->message = $message;
        $this->comment_at = new \DateTimeImmutable();

        // нам не нужен инкрементный идентификатор
        // мы можем сформировать естественный ключ
        $id = implode('_', [
            $page_id->id(),
            $author_id->id(),
            $this->comment_at->getTimestamp()
        ]);
        // хеш может давать коллизии и потому смотрите здесь сами
        $id = sha1($id);
        // упаковываем в Base64 для компактности
        $id = hex2bin($id);
        $id = base64_encode($id);
        $id = str_replace(['=', '+', '/'], ['', '-', '_'], $id);

        $this->id = new CommentId($id);
    }

    /**
     * @param PageId          $page_id
     * @param CommentAuthorId $author_id
     * @param CommentMessage  $message
     *
     * @return Comment
     */
    public static function comment(
        PageId $page_id,
        CommentAuthorId $author_id,
        CommentMessage $message
    ): self {
        return new self($page_id, $author_id, $message);
    }

    /**
     * @param CommentAuthorId $author_id
     * @param CommentMessage  $message
     *
     * @return Comment
     */
    public function reply(
        CommentAuthorId $author_id,
        CommentMessage $message
    ): self {
        return new self($this->page_id, $author_id, $message, $this->id);
    }

    /**
     * @param CommentMessage $new_message
     */
    public function edit(CommentMessage $new_message): void
    {
        // валидация должна быть многоуровневой
        // и на доменном уровне ее тоже нужно выполнять
        // сюда должны прийти уже валидные данные, но если они не валидны,
        // то это полный аллес капут

        $expire_at = $this->comment_at->modify(self::EDITING_PERIOD);
        if ($expire_at < new \DateTimeImmutable()) {
            throw new CommentException('Comment editing period has expired.');
        }

        $this->message = $new_message;
    }

    // Никаких сетеров. Далее толко геттеры по необходимости...
}

Книга Безопасность в PHP (часть 4). Недостаток безопасности на транспортном уровне (HTTPS, TLS и SSL)

Эта опция появилась в PHP 5.4.13. На момент написания этой части книги опция была доступна уже 10 месяцев.

Хм. То есть книга писалась в январе 2014. Не старовата ли книжечка?