https://en.m.wikipedia.org/wiki/Conway%27s_law
Про разбиение на модули тоже вот

Тогда советую поискать точки зрения, которые не сходятся с твоей)

так и делаю, да

Да, интересно)

Объясните, пожалуйста, где хранить логику целостности системы?
Например, есть сущность контракт и сущность компаниия. Между компаниями может быть заключено много контрактов. Каждый контрак и каждая компания имеют уникальный идентификатор, свои независимые поведения и проч. Когда создается новый контракт, то надо убедиться, что идентификаторы компаний не взяты с потолка и они реально существуют в системе. Где проводить проверку?

Я бы в хендлере сделал, который контракт создает. Ибо в контракт же уже валидированные данные должны придти

У меня таких хендлеров 3: rest, graphql, cli. Они используют один сервис в котором есть метод для создания контракта по атрибутам. Я этот сервис и дергаю. Но это же не домен, верно?

Это домен. Вы же озвучили бизнес-правило про “не с потолка”. Вам стоит гарантировать это на уровне домена

1 HMAC подпись для айдишника
2 забить. Я не увидел почему надо. От того что будут несуществющий айдишники ничего страшного не будет. Просто покажите их менеджеру и пусть он или удалит или еще чего решит

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

Ну вот в этом сервисе и проверяйте. "Контракт" и "Компания" - сущности одного контекста. В "Контракт " должен попасть только провалидированный идентификатор (ну или название) компании.

1. При чем здесь hmac?
2. На фронте разрабочики допустили ошибку и отправили несуществующие айдишники. Мне же надо убедиться, что мне не с потолка прилетели данные

1 подпишите айди hmac. Как получили проверили подпись убедились что он существует по подписи
2 что стращного если они допустили эту ошибку и вы сохраните? Как бизнес потеряет денег от этого?

Как это - что страшного?? Человек целостность пытается гарантировать

1. ЗАЧЕМ? Я могу просто у репозитория метод вызвать.
2. Что страшного если мусор в данных? Например, недополучит пару миллионов пока мы разбираемся что не так.

зачем?
ЧТо стращного елси челостность нарушится?
зачем тратить ресурсы и время на то что не вредит бизнесу и не принесет профита?

а почему нельзя просто обратиться из сервиса к CompanyRepository и спросить "существует ли запись с таким-то id?"?

мусорные записи в системе - это вредит бизнесу.

Да, можно. Вот я и спрашиваю где этот сервис должен быть. Это слой домена?

Вы не бизнес, что бы решать что принесёт или не принесёт профита. Человек пришёл с вопросом о консистентности - значит ему она нужна. Не перекручивайте всё просто так от неимения никаких вводных