но опять же, а вам правда надо эти все ВО?

мб я неправильно понимаю где должна проходить проверка уникальности email? в конструкторе Entity или VO?

Но основное VO все равно будет крупнее.

В доменсервисе

Есть конечено вариант, пропихнуть репозиторий емейлов в ентити или ВО - но это не айс. Но зато более жестко.

Но при этом сами VO и Entity не будут чистыми

Вы же смотрели Хорикова :) Вроде там было. Если нет, то в его книге

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

Тоже верно. Но возможно можно решить транзакциями при желании

Концепция уникальности email — это ответственность инфраструктуры. Не нужно это валидировать в VO

В целом тут уже тема поднималась, возможно вообще нет смысла чекать емейл, так как все равно констрейнты вышибет))

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

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

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

у тебя есть и другие процессы, как ты провалидируешь и обеспечишь уникальность в конструкторе?

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

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

@dexplon Volodymyr понял, благодарю)

Я сам задавался этим вопросом прмиерно в другом направлении:
Как я могу знать, что добавление картинки в статью - валидно, ведь у меня отдельно - сохранение картинки в ФС, отдельно создании сущности картинки и отдельно добавление картинки в сущность статьи. Я спокойно могу создать просто сущность картинки и сохранить в  статье. Но ведь  можно сервис картинок передавать прямо в сущность статьи и туда же аплоад файл или еще как.  Но по большому счету, кроме потери чистых сущностей я не получаю профита. Что за кейс "я могу", тут и логики нет -  где можно развалить консистентость.

Всем привет.
Подскажите решение довольно непростой задачи.

У меня есть монолит на 3.2, хочу перевести его на 5.1. Монолит состоит из 100+ связных между собой бандлов и все в 1 гит репозитории.

Я распиливаю проект, и связываю подпроекты между собой через композер

 "autoload": {
        "psr-4": {
            "": "src/",
            "tests\\": "tests/",
            "AppBundle\\": "../AppBundle/src"
        },
    },

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

НО!
Возникли проблемы
1 - шторм тупо не видит пространства имен подключаемых бандлов через композер
2 - сервисы все таки ссылаются друг на друга и видимо придется делать 2 вида сервисов, паблик для подключения другими бандлами и интернал, чтобы использовать только внутри бандла.
3 - все сервисы приходится объявлять в стилистике 3.2, т.к. кода нереально дохера.

Подскажите умные мысли на этот счет, если есть.

Спасибо