да центральная система. Не хотелось все это прокидывать, но видимо тут палка в двух концах.

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

Сейчас проблема такая что на каждый запрос, сервис идет в эту центральную систему и проверяет:
1. токен валиден
2. права на действие есть

Привет.
Подгружаю агрегат.
У агрегата есть бул поле isnew.
Если версия агрегата < 0 то isnew.
Конечно некоторые правила и методы предметной области не применимы к новому агрегату.
Поэтому в методе я вызываю проверку на New или не New.
Это не бизнес правило, поэтому это больше походит на спецификацию.

То есть
Void DoSomething()
{
Spec.isNewAgg(this)

CheckRule(Бизнес правило 1)
...
}

И теперь в большинстве методов весит какая то 'дебильная' спецификация - проверка на новый агрегат.
Как лечить?

что мешает передават все жто внутри токена и проверять его по публичному ключу например? Как самый лешкий вариант

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

звучит как какая-то закрытая сеть, только при помощи кролика 🤔

Вообще идея такая себе когада одному сервису нужно что то в другом
А как они друг у друга получают дело десятое
С таким же успехом можно в изолированную сеть их загнать и все будет рабоать

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

сделать два отдельнх новый и старый

Приходит команда.
В команде id
Если такого потока не существует, то агрегат стор возвращает новый агрегат

А на языке бизнес-кейса что происходит?

Создаётся новая заявка.

Когда новая заявка перестает быть таковой?

Когда она скофигурирована.

В изолированной сети, мне ведь тоже нужно убедится что у сервиса А есть права на действия в сервисе Б. И мне все также необходимо идентифицировать запрос, что он именно от сервиса А а не от сервиса Д.

Возможно это два разных объекта: Новая Заявка и Сконфигурированная Заявка

зачем? Не очень понимаю если вы их всех  контролируете? Просто не отправляйте запросов из Д которых не должно быть

ну самый простой пример, мне надо понять кто последний изменил некую сущность в сервисе А. Это сделал сервис Б или сервис Д ?

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