Я довольно новичок в DDD, но мне нравится, как дизайн навязывает структуру в вашем коде (если вы придерживаетесь принципов). У меня есть загадка, в которой я верю, что для решения проблемы мне нужно пожертвовать дизайном, чего я не хочу делать. Но прежде всего я хочу отметить, что, возможно, с самого начала я проектировал это неправильно из-за своего невежества.
У меня есть приложение, в котором есть объект, содержащий BLOB в терминологии базы данных. Давайте назовем эту сущность child. Следовательно, child имеет большой размер, поскольку содержит BLOB. Теперь, child можно найти из его идентификатора AR, назовем AR parent. Существует также еще один уровень выше (grandparent), но этот уровень не требуется, поскольку child содержит требуемые данные для передачи пользователю, а parent можно найти по запросу пользователя (некоторые сложные поиски требуется на стороне приложения для получения родителя, хотя).
Теперь, parent содержит множество child (отношение один-ко-многим), но мне нужен только один child на транзакцию, поэтому запрос всего результата parent и child на запрос определенно не нужен. Выполнение этого запроса для каждой транзакции также было бы невероятно неэффективным, поскольку я запрашиваю множество дополнительных данных из БД, которые я даже не использую в каждой транзакции. Это было бы экспоненциально более эффективно, например, хранить parent локально и выполнять запрос для одного child.
У меня также узкий SLA, поэтому получение child должно быть невероятно быстрым. Мой текущий подход грубой силы состоит в том, чтобы запросить parent, получить только один из child и предоставить результат пользователю. Я ищу подход, в котором я могу иметь parent локально, без списка child, затем, когда приходит запрос, я запрашиваю один child. Это было бы невероятно быстро и эффективно, так как я получаю только то, что мне нужно. Но это нарушило бы правила DDD, поскольку технически на child ссылается только личность parent, и он не будет собственным AR.