领域驱动设计拙见

领域驱动设计并不是技术，而是一种思想，目的是为了降低业务代码复杂度。

一、核心

1、领域

领域可以理解成模块，比如微服务系统拆分，可以分成交易、商品、营销、结算等。也可以拆分的更细，比如说营销域，可以拆分成活动子域、权益子域等等。
核心是将某个功能或者模块，构建成一个高度自治的整体。向领域输入或者输出都得转换成该领域的语言（防腐层，或者叫适配层）。

2、限界上下文

限界上下文这个名词有点唬人，按我个人理解其实就是领域的边界。
只有清晰了领域之间的边界，才能将领域构建成一个高度自治的整体。比如说微服务拆分算是边界划分，在比如说结算域还可以拆分成计费子域、分账子域等等。粗粒度拆分还是细粒度拆分，完全取决于团队的承载能力。

3、分层

分层就是各司其职。计算机发展过程中，很多软硬件设计都遵循该思想。
比如说：

1. 网络七层协议（应用层、表示层、会话层、传输层、 网络层、数据链路层、物理层）
2. I/O层次结构（用户应用层软件、中断处理程序、独立于设备的软件、设备驱动程序）
3. Mysql分层（连接层、服务层、引擎层、存储层）

分层的好处：

1. 将大问题拆解成小问题
2. 可插拔。比如说Mysql引擎层，就可以通过配置使用InnoDB或者MyISAM。
3. 低耦合，有良好的扩展性。修改某层的内容，不影响上下层逻辑。

4、实体

DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
可以是和数据库一一对应的对象，也可以是业务对象（按我理解就是DDD的聚合根）。
其实叫啥不重要，怎么组成的也不重要。
重要的是实体要有基本的属性，也需要有业务能力。
比如说人由头、身体、腿、脚等等组成，人还有看、听、闻、讲、动等能力。就可以认为是一个实体或者说聚合根。

二、如何做业务

1. 领域能力抽象（对业务对象进行能力建模，可以是应用内部的Manager，也可以是RPC服务）
2. 业务流程编排（对能力进行流程编排，组织成业务）

1、中台

2、应用开发

业务流程可以采用工作流的方式编排，可视化输出。方便产品大大了解业务代码的流程。