DDD尝试解决业务系统(逻辑+CRUD)开发的复杂性问题，这种复杂性是由于复杂的业务规则，业务逻辑变化。
一般系统的业务逻辑、复杂性在于：流转判断多，专业规则多，计算量大。而DDD模式的解决的方式是通过分层，即业务逻辑、实现分层，以业务逻辑为核心进行开发。
DDD开发是基于对象开发的更为抽象的阶段，通过业务领域的分析，获得业务逻辑、规则的清晰边界，分类，而后进行开发。

以下从数据开发模式分析，对比DDD开发模式的路径、定义、实现以及适用的场景。

1. 数据驱动开发

基于数据开发的问题：

过早地进入了实现领域的讨论，可能会忽略重要的业务规则，也不利于我们技术和业务持续地进行交流 。技术复杂性和业务复杂性混杂，容易顾此失彼。

 

 分层结构的问题：

 

 2. 领域驱动设计

要点：统一语言，抽象层面的领域模型，抽象度高利于业务模型重用，专注业务领域，业务文档与代码层的统一，业务逻辑集中不分散

面向对象（业务）——领域对象，包括属性、业务方法与行为，关联

实现过程探讨：

1. 业务需求分析， 确定业务对象、属性、逻辑、规则，建立业务文档，明确技术层面不能影响业务逻辑。

2. 开发独立：界面层，应用层（日志，事务，持久化等系统基础设施层面与领域无关层），业务逻辑层

3. 技术层级的解耦：IOC，AOP，（反射）

以上： 有利于信息化（核心业务高重用，独立，基础设施不重复搭建，逻辑隔离开发简单），支持持续构建，集成，敏捷开发

实现工具：mindmap, uml（泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖）, 时序图，流程图（ Opt 选项 ,alt 抉择 ,loop 循环 ,break 中断 ,par 并行 ,critical 关键 ,seq 弱顺序 ,strict  强顺序）

TDD开发

补充：

业务规则-Business Rules ：业务规则是指对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示业务行为，采用类自然语言来描述，并集中存储在规则库中。业务规则由业务人员创建、实时更新和调试，业务规则之间的复杂逻辑关系由规则引擎处理。业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。

 Bounded ContextsMap 业务边界，ACL--访问操作的保护,interface, Down UP domain;OHS
 Aggregate 聚合，业务上具有强关联的业务对象，在场景中可以作为一个范围内的对象分析。
 Entities 实体，具有唯一标识，例如汽车-发动机编号，单据-单据编号，
 Value Object 值对象，例如syscode, codeTable,没用唯一标识，具有强烈的数据属性
 Services 无状态逻辑, 
 Domain Events，Domain 层的对象应该保持简单，不依赖于任何的第三方外部框架，保持灵活度，
 Factories
 Respositories 数据资源的使用, Persistence Object 持久化对象

一个分层整洁架构的思路：