领域驱动设计和安全
这与这个 问题 相关，该问题似乎不久前就已经问过了。项目中的安全实现遵循域驱动设计的基本原则。让我举一个
银行系统的例子：
使用案例：正在存入新的银行存款，需要批准，因为这是第一笔存款
a。入金金额<5000店员可自动授权
b.经理可以有两种类型 - 银行经理/客户经理。只有账户经理可以授权任何存款 > 5000 的账户
我的担忧如下（如果担忧本身正确，请纠正）
- 不确定我应该在哪里构建以下逻辑 - 负责检查登录用户是否有权做某些事情时要考虑到他的头衔 - （本例中是客户经理）。授权是一个用例，但安全层似乎对域对象有深入的了解
- 一般授权（而不是身份验证）。我知道基于角色的身份验证会有所帮助，但问题是“在哪里” - 在哪一层和调用流程中。 UI 层是否应该调用某个安全层，或者域层是否会针对所有可能的组合进行自身验证？
请帮忙。这非常令人困惑。
看看这是否引起专家的注意
干杯
This is linked to this question which seems to have asked a while back. Security implementation in a project that is adhering to basic principles of Domain driven design. let me give an example
Banking System:
Use Case: A new bank deposit is being made and requires approval as it is first deposit
a. Clerk can auto authorize if the deposit amount is <5000
b. Manager can be of two types - Bank manager / Account Manager. ONLY Account manager can authorize any accounts that have deposit >5000
My concerns are as follows (Pls correct if the concern itself is correct)
- Not sure where should i build this following logic - takes care of checking whether the logged on user has authorization to do certain things taking in to account his title - (this case Account manager). Authorizing is a use case, but the security layer seems to have intimate knowledge on the domain object
- In general Authorization (not authentication). I know that Role Based authentication would help, but the question is "where" - in which layer and the call flow. Should the UI layer call on some security layer or would the domain layer validate itself for all possible combinations ?
Please help. Its very confusing.
Bump to see if this gets experts notice
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
安全性是一个跨领域的设计功能，可以影响所有类、方法和属性。
从 DDD 的角度来看，您会选择规范和角色。
这些规范的实施地点和方式取决于您的架构。您可以使用方面，可以使用内联调用、事件等。
以下是我要查看的有关安全性和角色的一些链接：
Security is a cross-cutting design feature which can affect all classes, methods and properties.
From a DDD perspective you would go with specifications and roles.
Where and how those specifications get implemented comes down to your architecture. You could go with aspects, you could go with in-line calls, events, etc.
Here are some links I would check out regarding security and roles: