领域驱动设计和安全答案

【问题标题】：Domain Driven Design and Security领域驱动设计和安全
【发布时间】：2011-03-30 18:39:41
【问题描述】：

这与question 相关联，该question 似乎已经问过一段时间了。项目中的安全实施遵循领域驱动设计的基本原则。举个例子吧

银行系统：
用例：正在进行新的银行存款并需要批准，因为它是首次存款

一个。如果存款金额湾。经理可以有两种类型 - 银行经理/客户经理。只有账户经理可以授权任何存款>5000的账户

我的顾虑如下（如果顾虑本身正确，请纠正）

不确定我应该在哪里构建以下逻辑 - 负责检查登录用户是否有权执行某些操作，考虑到他的头衔 - （本例为客户经理）。授权是一个用例，但安全层似乎对领域对象有深入了解
一般授权（不是身份验证）。我知道基于角色的身份验证会有所帮助，但问题是“在哪里”——在哪一层和呼叫流程中。 UI 层应该调用某个安全层还是域层会针对所有可能的组合验证自己？

请帮忙。它非常混乱。

看看这是否引起专家的注意

干杯

【问题讨论】：

【解决方案1】：

安全性是一个跨领域的设计特性，它可以影响所有的类、方法和属性。

从 DDD 的角度来看，您将使用规范和角色。

这些规范的实施地点和方式取决于您的架构。你可以使用方面，你可以使用内联调用、事件等。

以下是一些关于安全性和角色的链接：

【讨论】：

感谢您的快速回复。我正在看。
感谢您的快速回复。 RBAC 是一个有趣的链接，但我更多的是查看一些示例/快速接口/类，它们可以让我了解它的外观。这里的新手，理论上可以得到它。几乎在学习阶梯上。
坚持的时候来不及了。您应该在执行域逻辑之前进行授权。不是在执行逻辑并尝试持久化之后
@tuespetre 他指的是持久性/基础设施层（意思是在创建域对象之后）。在我看来，授权过于模糊/笼统。实际上，问题中的示例是域逻辑。应该在域中处理
@Tudor 又过了一年零几个月，我不得不说我同意你们两个。该问题描述了应该在域中建模的规则，但应用程序/服务层负责协调域对象之间的交互，从而确保实际调用授权逻辑。