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

Не согласен с чем?)

с "Сущность без зависимостей бесполезна"

Зависимости есть direct, есть indirect. Твоя "сущность с пачкой VO" будет иметь как минимум одну indirect зависимость. Ведь её кто-то будет использовать, верно?

тогда это не её зависимость, это от неё зависимость. Мне кажется это существенное различие

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

Сервису нужен репозиторий. В тестах его репо замокать и передать в конструктор. А какой твой вариант?

я бы не мокал, а бы пытался покрывать такое каким-то более высокоуровневыми позитивным тестами (типа е2е или тестов на апи), т.к. в этом "сервисе" не должно быть иф-ов и тогда один позитивный тест-кейс всё протестит.
а вот сущность, которую вызывает этот сервис перед тем как сохранить её в репозитории можно тестить легко с использованием VO без моков

под сущностями подразумеваются не Эвансовые/ddd-ные сущности, которые pojo с identity?

То есть, твой тест полезет в реальную базу данных, которую ему нужно создать и добиться, чтобы в БД было консистентное состояние? Что, кстати, сильно замедлит тесты. Тогда что будет, если твои тесты запустить в несколько потоков? Скажем, 10

почему не делает? оно принимает что-то на вход, принимает какие-то решения и выплевывает что-то на выход)

Есть масса способов "убрать" зависимости

Если у сущности 0 direct и 0 indirect зависимостей, то она пометится в IDEA как unusable:) Потому что её никто не использует и она просто лежит в коде. Но если откинуть indirect, то да, это вполне может быть leaf нода

что за термины такие интересные...

Есть "зависимости" - это штуки от которых зависит твой модуль. Есть "пользователи" твоего модуля, они на модуль не влияют а потому их можно не рассматривать (они в целом влияют на формирование интерфейса - как никак мы под клиентов проектировать должны а не в вакууме но все ж)

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

клиентский код не может быть "зависимостью", хз откуда ты придумал этот термин (inderect)

может быть ты путаешь с afferent/efferent (fan in/fan out)

Попутал с afferent - efferent

Да

нет, не полезет. Я не люблю нарушать границы модулей в тестах. Этот тест будет стучаться в апи. Чтобы добиться консистентного состояния в бд - можно использовать то же самое апи (опять же мне не нравится нарушать границы модулей).
Что касается замедления тестов - я бы постарался просто не делать их много. Это тесты, которые говорят о том, что система в целом плюс-минус работает. Там не будет много вариаций за счёт того, что будут проверяться только позитивные и самые важные сценарии + если иф-ов в сервисах нет, тогда и комбинаций меньше.

опять же - зависимости разные бывают. Есть те же "репозитории" которые там "достань мне красненькую". А есть зависимости с сайд эффектами (отправь email). А есть зависимости ради зависимостей - "достань красненькую - может то что вернулось еще и желтенькое? тогда сайд эффект".