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

CheckRule это бизнес правила для агрегата.

Просто я возможно неправильно понял коллег.
Мне говорят чтобы агрегат ПОЛНОСТЬЮ валидировал себя

Но мне кажется это немного бредом

Валидировал наверное все таки ближе к ПРОВЕРКАМ изменений влияющих на стейт агрегата

Kак то так.
Ну спасибо.
Думаю бизнес правило проверки автора не нужно.

Заявка может существовать без автора.

Получаешь противоречие со своим утверждением, что у заявки ДОЛЖЕН быть автор.

Хорошо, у меня сейчас такая проблема:

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

У меня есть корзина. Когда пользователь оформляет заказ: я из корзины создаю заказ, при этом мне надо провалидировать, чтобы правило на максимальное количество товара выполнилось для каждой позиции.
Что я делаю сейчас: у меня есть юзкейс. Через репозиторий узнаю количество каждого товара и отдаю в виде dto'шек результат в виде ([product_id: 3, quantity: 6], [product_id:7, quantity: 8]). Этот массив данных обхожу циклом и валидирую его на максимальное количество.

Примерно так происходит:
function TransferCartToOrderUseCase()
{
   $productQuantities = $this->cartQuantityRepository->getQuantitiesByProduct($cartId);

   foreach ($productQuantities as $productQuantity) {
       $allowedQuantity = $this->productsLimitRepository->getAllowedQuantity($productQuantity->productId);

       if ($allowedQuantity < $productQuantity->quantity) {
           throw new Exception('Not allowed quantity for dish');
       }
   }
}

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

Если правило будет нарушено, то мне прилетит по башке, потому что менеджерам придется звонить клиентам и извиняться.
Т.е. там нет такого, что ты оплатил заказ и он уже 100% доставляется. Это больше не заказ, это больше "заявка на заказ".
Например. Доступно 10 штук обоев
Первый клиент оставил заявку на заказ 5 штук, второй на заказ 3, третий на заказ 2. и тут приходит четвертый клиент и хочет заказать еще что-то. После каждого заказа число в табличке уменьшается. Если менеджер звонит и с клиентом не находят общего языка - то число увеличивается.

В данном случае, когда третий клиент оставил заказ - число доступных стало 0

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

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

Может, оцени риски

Многие так и делают

Аля идентити мэпа такая или unit of work

Как раз для этого и нужно)
Чтобы декорированием вызывать комит у UOW.
Так как SerializedEvent далек от домена и внутреннего устройства агрегата, то мне нужна обертка для того чтобы в агрегат сторе сохранить

Ну тогда зачем вот эти агрегаты и прочее?

Что если у тебя должен быть отдельный агрегат для "доступности товара" и тогда нет нужды в куче непонятных сервисов

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

Никак не будет связан