我对什么是最佳实践/模式有疑问，以确保在我的SOA应用程序中进行适当的授权。我有一堆服务允许用户访问某些数据（存储在数据库中）。典型情景的一个例子是......
我们有一个EMPLOYEE表，表示与PROJECT的一对多关系。因此，员工可以拥有许多项目。每个员工也属于一个地区。允许系统用户编辑有关员工和项目的信息。但是，每个用户只管理一些区域的数据，因此只能修改属于用户管理区域的员工及其项目。因此，用户可以访问区域A，B，C，并且可以编辑区域A员工的员工/项目数据，但不能编辑区域Z员工。
我有一项服务可以让您编辑员工，另一项服务可以编辑项目。类似地，项目与其他实体有关系，例如， SCHEDULE，我也有编辑这些的服务。
然而我的问题是这样 - 用户是否可以通过调用相应的服务来编辑项目或计划，取决于员工（这些项目和计划相关的）属于哪个区域。因此，对于每个服务来修改项目或计划或从员工开始的该数据层次结构中的任何实体，我不得不查询相应的员工并强制执行区域约束。考虑到数据库调用和连接数（我的真实例子有很多这样的实体和相应的服务），我必须在每个服务调用上进行，这可能会变得非常昂贵。对于我的场景，是否有更优雅的轻量级解决方案？
答案 0 :(得分：1)
首先，我将这些要求称为常规业务规则而不是授权。授权通常更通用，意味着是否允许用户访问特定系统或允许用户调用某个功能（无论参数如何）。
其次，基于业务规则视图，在将业务划分为服务之前，应考虑这些业务规则的一致性需求。
第三，关于你的陈述＆＃34;我的真实例子有很多这样的实体和相应的服务＆＃34;，拥有与实体相对应的服务通常不是一个好主意。
因此，总而言之，您需要重新设计服务边界，以便需要强制执行的规则（以高度一致的方式）包含在单个服务中。一种方法是采用给定实体的不同部分并将它们放在不同的服务中 - 前提是没有任何业务规则要求在这些不同的服务之间保持一致