我在服务之间划分责任时遇到了问题。
想象一下，我们遵循减少的服务数量，通过RabbitMQ相互通信：
实现用户创建功能：我应该在API或用户服务中强制执行业务限制吗？
例如，如果只有管理员可以创建设置为true的“isAdmin”属性的用户，则会出现以下选项：
API服务检查用户是否已获得授权，如果是，则将操作发送给用户服务。操作用户服务。
优势：用户服务更灵活。如果其他服务想要在将来创建用户，则不会限制执行它想要的任何事情（例如，创建没有“创建者用户”的用户）。数据也会尽早验证。
缺点：如果业务逻辑太常见，我必须在多个点复制支票。我有用户拆分的业务逻辑
用户服务检查授权并向API返回错误。 API将该错误传递给客户端。
是否存在任何良好做法？你以前遇到过这种困境吗？它是如何工作的？
答案 0 :(得分：0)
从Domain driven design的角度来看，授权应该是一个单独的有界上下文。因此，授权检查应在Users administration bounded context之外完成。因此，在最简单的实现中，您可以使用一些Api服务来执行实际检查，从Application层调用。如果当前经过身份验证的用户具有所需权限（例如CanCreateNewUsers），则允许调用Users administration bounded context，否则将被拒绝并显示错误。
更复杂的/ DDD解决方案是在两个有界上下文之间使用Anti-coruption层。
顺便说一句，我建议您在进行实际检查时使用权限而不是角色。您可以在Authorization bounded context。