我在整个堆栈上遵循干净的架构/坚实的原则。我遇到了一种情况,我想将 UUID 嵌入到域逻辑中的一些实体 id 字段中,例如:
OrganizationEntity
id=abc123ItemEntity
并在创建时将拥有该 OrganizationEntity
的 ItemEntity
的 id 嵌入到 id 字段中,即: Item.id = itm-abc123-sdfnj344
我正在考虑走这条路线,这样我就可以减少数据库查找的数量,以查看是否有人可以访问 ItemEntity
- 如果客户端请求属于 OrganizationEntity
,那么我可以在两个客户端请求上进行模式匹配 abc123会话 ID 和请求记录 ItemEntity
...这将大大提高性能。这是已知的模式/实现吗?有什么疑虑或问题吗?
尝试使您的领域模型尽可能接近领域专家的语言。因此,如果
Item
属于某个组织,则可以在 Item
中拥有参考 ID。但是,如果一个项目属于另一个域对象,并且该项目属于一个组织,则由于性能(持久性)原因,您不应引用项目域对象中的组织。
您说您想检查是否有人可以访问
ItemEntity
。这意味着存在一种上下文,其中 ItemEntity
对象是可访问的。
我看到了 3 个选项来实现这样的上下文:
具有 组织 id 参数
的存储库 APIpublic interface ItemRepository {
public List<ItemEntity> findItems(...., organizationId);
}
当您在每次存储库调用时传递组织 ID 时,存储库是无状态的。但这也意味着您必须将组织 ID 从控制器传递到用例,然后传递到存储库。
与组织绑定的存储库
公共项目存储库{ 私有 UUID 组织 ID; // 这里省略了构造函数
public List<ItemEntity> findItems(...){}
}
当您创建绑定到组织的存储库时,您必须在需要时(以及用例)创建它,因为它是有状态的。但你可以确定没有人可以获得他不被允许看到的物品。
呼叫上下文中的组织 ID
调用控制器时,它会从会话中获取组织 ID,将其放入调用上下文中并调用用例。在 Java 中,您将使用
ThreadLocal
。您还可以将其实现为一个方面并将其应用到每个控制器(AOP)。然后,存储库实现可以访问调用上下文并获取组织 ID 并在查询中使用它或在返回项目之前过滤项目。
此选项将允许您访问控制流中每一层的组织 ID,例如在所有用例、实体、存储库或调用外部服务时。
在所有三种情况下,您都可以避免仅出于数据库访问原因而将组织 ID 放入项目中。