DDD案例分析

领域层级划分

一般分为这各个层view，service，domain，dao，entity，infrastructure，第三方库libs/Utils

Dao（数据库访问，对数据库的增删改查，不涉及业务逻辑， Dao在数据库和业务逻辑（Service）之间）

Service

主要是业务逻辑，只考虑逻辑上的业务，不考虑具体的实现，如果需要数据库操作通过Dao层实现。

Domains层：

主要处理业务逻辑，以及比较偏底层的一些业务处理。

Entity层

放置一个实体以及对应的set/get方法，如果需要对数据库进行一些操作就要写entity层。

Utils层

工具类层，通用的、与业务无关的，可以独立出来，可供其他项目使用。

View层

主要放用户界面类

Service层

Service就是用户业务，在最上层，主要表现为用户的一些操作集合，比如说打开文件，数据标记等等

Service调用domains层。Domians层处理一些负责的业务逻辑。

Domains层调用Dao，Dao调用数据库。
 

Service对应业务领域（每一个业务领域都可以划分类几个子域，而domains中放的就是对应的子域（包括核心域，支撑域，通用域））

Domains就支撑了上次Service的运行

Entity层就对应了最小实体, 聚合根，值对象等。

Uitls就是共用的一些库等。

Infrastructure：如果涉及到硬件数据读取，就在基础设置层中去实现，这是在DAO的更底下的一层。

Context层确定了每一个域或者实体之间的关系。（它代表了域和域之间的联系。）（BoundContext）

DDD只是粗略等对业务进行分类分层，具体的实现还会设计许多的东西。向域和域之间的通信，业务的抽象等等，还需要根据实际的业务和产品中的问题来处理。

Service层和view层一般是平级的

案例是一个经典的电商系统：

业务功能包含用户管理，商品管理，订单管理等核心功能。

第一步：领域划分：

基于上面三个业务功能：划分为三个子域，

1. 用户服务（user service）：负责注册，登录，个人信息管理等。
2. 商品服务（product service）：负责商品信息管理，架构更新等。
3. 订单服务（order service）：负责订单的创建，取消，查询等。

第二部：领域建模

通过各个域的子对象各自的属性以及他们之间的活动来支撑这个功能的正常运转就是建模。

第三步：接口设计