1.DDD概念

我们先看DDD的单词组成:Domain（领域）driven（驱动）design（设计）

简单理解：这里有两个名词，领域与设计。所以这是一种通过领域这种模型来指导（或驱动）程序开发设计的一种方法

所以DDD的重点就是领域。

那么什么是领域呢？

领域是拓扑学一种概念。比较拗口。我们理解为它的近义词：范畴、范围就更好理解了。

举个栗子：任何一个系统都会属于某个特定的领域，都有一个自己的范畴，比如论坛是一个领域，只要你想做一个论坛，那这个论坛的核心业务是确定的，比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。所以，同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。

因此，我们可以推断出，一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。

2.领域驱动设计的总体架构

• 表现层：负责显示和接受输入；
• 应用层：很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；
• 领域层：包含整个应用的所有业务逻辑；
• 基础层:：提供整个应用的基础服务；

DDD领域驱动设计的优点就包括：

1.从技术维度实现分层：能够在每层关注自己的事情，比如领域层关注业务逻辑的事情，仓储关注持久化数据的事情，应用服务层关注用例的事情，接口层关注暴露给前端的事情。

2.业务维度：通过将大系统划分成多个上下文，可以让不同团队和不同人只关注当前上下文的开发。

3.时间维度：通过敏捷式迭代快速验证，快速修正。

3.如何划分领域聚合

• 聚合的定义

聚合，字面意思就很简洁明了，是把领域对象聚合在一起，并维护领域对象之间的关系。我们来解释下这句话中出现的几个名词：

所以我们总结下聚合的定义：聚合根发起的，并维护多个实体间固定业务关系的领域对象。

• 这里举个领域划分的栗子：

公司部门权限小系统，用户表 User、角色表 Role、用户角色关系表 UserRole、部门表 Department、菜单表 Menu、菜单角色关系表 MenuRole，共六个表，

首先呢，根据我的想法，只要对一个模型操作，就必须建仓储 Repository ，那它就是一个聚合，所以：聚合和仓储基本是一对一的，有一个仓储就是一个聚合。

所以现在有四个聚合了：

聚合1：Department

聚合2：Menu、MenuRole、Role 三个， 聚合根是 Menu

聚合3：User、UserRole、Department、Role 四个，聚合根是 User。

聚合4：Role、User、UserRole、MenuRole、Menu 五个，聚合根是 Role。

然后再从关系表中看，用户和角色是多对多的关系，所以需要把 UserRole 作为一个新的聚合

聚合5：UserRole、User、Role 三个， 聚合根是 UserRole