应用程序是用PHP / Laravel / Doctrine编写的要约墙，我们在其中创建了由应用程序用户创建的墙，我们提供了需要显示在墙上的内容，并且有一些不是app的最终用户标识符用户，它在系统中没有自己的表，它只是一个字符串标识符。因此，我将应用程序划分为帐户BC（我们拥有与应用程序用户相关的内容），提供BC和限制BC。在此示例中，我们将使用BC墙。
我有这样的数据库结构（简化）：
墙：
wall_devices：
wall_user_device：
wall_banned_users：
wall_points：
因此，乍看起来，wall是一个聚合根，而墙ID是一个聚合标识符，对吗？
让我们提供一个示例流程，我们需要为某些最终用户打开一堵墙（请记住，它只是一个字符串），因此我们有一个包含wall.id和end_user_id数据的请求。步骤：
WallRepository得到wall聚合end_user_id选择的设备。在这种情况下，我们需要向wall_user_device表查询数据库（注意，我告诉查询数据库而不是在DDD存储库中使用存储库bz应该只对整个集合起作用），因为无法将其作为一部分的wall中，对吧？再举一个例子，最终用户完成了一些报价，因此我们需要检查最终用户是否存在wall_points，并更改点的状态，因此我们再次要求wall.id和{ {1}}数据：
end_user_id得到WallRepository聚合wall实例并进行更新（如果存在）。因此，这里再次需要查询数据库，因为无法使用wall_points聚合来获取数据。因此，在这一点上，我感到wall聚合的设计不正确，因为他所做的唯一操作就是仅操作wall表，并获取我们需要的所有其他数据结合使用wall / wall_id进行其他查询。
因此，在逻辑上似乎是以某种方式围绕end_user_id组合创建聚合作为聚合根实体标识符，并从存储库中获取所有数据作为单个聚合。但是我猜想，如果可能的话，需要创建一些变通方法以将几个教义实体合并为一个DDD实体
或者另一种可能的解决方案是仍然使用wall_id-end_user_id作为标识符，仅通过wall_id连接所有数据，然后再通过wall_id过滤数据，但是在这种情况下，我们将查询/处理大量数据，因为隔离墙可能有大量最终用户，这将对应用程序性能产生不良影响。
也许有人遇到类似的问题，可以帮助我在此处做出正确的架构决策吗？
此外，我想指出的是，这是一个现有/旧版应用程序，具有非常大的数据库，并且该应用程序的这一部分正常工作，因此不希望更改数据库结构。