DDD 领域驱动设计

领域驱动设计（Domain Driven Design）是大型业务系统最常用的方法论，是现有微服务业务拆分的一个基础理论，是架构设计中很重要的一个方法论。但是，领域驱动设计又是一个比较庞大复杂的理论，包含实体、仓库、聚合、边界上下文、服务等理论，初学者可能会角色比较晦涩难懂，在具体实施上可能也会觉得晦涩难懂。

为了逐步学习 DDD，我们以一个简单的权限系统的设计为样例，一步步去理解相关的概念和系统结构设计。案例如下：

●
权限系统包含两种账号模式，分别是用于用户登陆访问的用户账号和用于 api 授权的服务账号，用户账号通过手机号和密码进行访问，api 账号通过 ak 和 sk 进行授权访问

●
系统有一批默认的权限策略，每个权限策略约束了一组权限，比如 UserSystemReadOnlyPermPolicy 表示对 UserSystem 这个模块的只读权限，一个策略可以赋予给多个账号，一个账号可以被赋予多个策略，暂不考虑 Policy 之间的优先级。一个权限策略的样例如下：
name
UserSystemReadOnlyPermPolicy
desc
用户系统只读权限
rules
●
effect：allow/deny
●
resource: rac:$scop:${module}:$name/${extension} 资源描述符，可以描述任意一个资源
●
action：[‘readInfo,listInfo’] 具体能执行的操作

●
账号的权限可以转交，但是不同账号之间的权限不能互相转交，比如用户账号的权限不允许转交给 Api 账号，且如果账号存在异常也不允许转交

●
授权关系采用和权限策略相似的类型进行处理，每增加一条授权规则即增加一个 Rule，授权的 resource 固定为：rac:public:attach:permPolicy:${policyName}

根据案例描述，大致的模型结构如下所示：
UserAccount
ApiAccount
PermPolicy（权限策略）
AuthPolicy（授权关系）
n…n
1…1
1…1
Rule
1…n
1…n