Хорошо, пусть будет VO. Хотя в данном случае одно другого не отменяет.

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

$checker = new UsernameAlreadyRegisteredChecker();
$usernameFactory = new UsernameFactory($checker);

$username = $usernameFactory->createUsername('John');

Меняю имя в сущности User (опускаем рефлексию, простая идентификация):

(new User($userId))->changeUsername($username);

Потом повторяю операцию с тем же именем, но с другим ID. Имеем дубль имени. Скорее всего ты опустил что то типа

$this->checker->addStorage((string)$instance);

перед ретурном в createUsername()

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

Но ты же сам писал про защиту от дурака:

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

Тут похожий принцип.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Аллилуйя.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Если ты Hello World пишешь, или бложик - то DDD вообще не нужно.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Осмелюсь предположить, что есть сервис, который меняет имя? Там тоже

Получается, что на любой чих нужно сохранять объект User в репозитории и доставать его снова. Хм...
Интересно посмотреть на реализацию UsernameAlreadyRegisteredChecker

Это детский аргумент из области старых холиваров OOП vs процедуры. Тоже считалось, что без ООП большой проект не сделать. А сейчас, когда вошла в моду слоистая архитектура, сервисы по сути стали процедурными. Я уже про мидлвары молчу

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

И вообще, ты знаешь, что есть куча народу, которая придерживается принципа анемичных моделей, а они противоречат не только принципам DDD, но и ООП в целом. Не думаю, что все они пишут Hello World.

Так что это не аргумент. Хотя я же не говорил, что DDD отстой. Мне не нравится, ну и что теперь. Или ты хочешь сказать, что я одни бложики пишу?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Какой еще "любой чих"? Если у тебя в предметной области пользователь имеет возможность поменять своё имя, то как ты без сохранения это сделаешь? Или ты в процедурном стиле не напишешь где-то UPDATE в случае с РБД?

Это либо репозиторий, либо сервис, имеющий доступ к репозиторию.

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

Какое еще опосредованное значение? Название темы прочти. Это тебя несёт в сторону похоливарить, а тема про DDD и как лучше спроектировать конкретный участок системы.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

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

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


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Так же как и php не обязателен. Однако, как ты мог заметить, мы находимся на форуме phpforum и прямо сейчас разбираем код на php

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Причем тут PHP))) Я про то, что слишком все усложняется. Если хочешь аналогию с форумом, то написать Привет мир! можно через echo, а можно задействовать TWIG. Просто ты говоришь, что большого проекта без TWIG не построить. А я говорю - херня, можно обойтись нативом.

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

Это риторический памфлет, не принимай близко к сердцу. У каждого свои бзыки свой путь.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

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

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

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

Ну так навскидку, вот это фигня какая то:

        if ('' === $username) {
            throw new \InvalidArgumentException();
        }

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

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

И вопросик... Это ты по приколу так пишешь или реально?
UsernameAlreadyRegisteredCheckerInterface

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да это же просто прототип, там даже нет сообщения в исключении. Данная "проверка" демонстрирует наличие минимального поведения у Username. В реальности там будет использоваться нормальная валидация.

В каком смысле "по приколу"? Тебя длина названия что-ли смущает?

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Да.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ну да, я так пишу. Не такое уж и длинное название, вообще-то

------------------------


Не совсем по теме, ибо сильно вдаюсь в детали реализации, но ситуация и архитектура очень похожа на мою.
На стэке древний топик с обсуждением проблемы касательно доменных репозиториев с простым API: https://stackoverflow.com/questions/2015451...queries-in-cqrs

Вкратце: есть предложение перекладывать ответственность по проверке на дубликаты на клиента, используя read-часть.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль