Закон Деметры и Doctrine?
Можно рассмотреть схему, при которой модуль сам предоставляет другим возможность использовать свои данные. В данном случае - внешний интерфейс с методом, достраивающим внешний запрос в соответствии с теми фильтрами, которые переданы в функцию. А также методом, возвращающим описание возможных фильтров - так, чтобы вопрос, что вообще можно запросить у модуля, решался не вне его, а в нем же самом. Так внешний модуль ничего не будет знать об используемом, но при этом сможет использовать его данные.
то как быть с ситуацией, когда в некоторых модулях должны производиться сложные выборки с фильтрами, агрегацией, затрагивающие сущности (entity) других модулей?

Для решения задач в другом модуле/домене нет необходимости иметь сущности др проекта/модуля/бандла. Пример в модуле доставки 
не нужно знать ВСЕ о товаре и логике его сбора, нужно знать размеры и название
в этом модуле не нужно знать и о заказе все — только адрес, время. История его обработки и статусы (все это есть в агрегате/сущности Заказ), влияние акций и промо — это знать не нужно, но оно есть!... передавая сущность куда-то вы передаете знания и связываете разные модули
не нужно знать о пользователе много, кроме телефона, имени и адреса


Потому вы можете из БД выбирать только необходимые данные конкретному модулю. Этакие проекции по потребностям. Это есть соблюдение закона Деметры — вы не лезете в другой модуль, вы лезете в инфраструктуру (вселенную), которая даст вам ровно те знания и состояние, которые нужны . То есть за своими данными.. Более того эти знания могут собираться различными способами и не обязательно из реляций доставаться, а могут быть агрегированные в NoSQL виде к примеру.

Крч для одного модуля вы получаете некоторые проекции/данные, которые в этом модуле вы даже не скажете — откуда они пришли, тк нет этих знаний — из персистенс-слоя и все...