凯京科技成立已三周年，其技术架构经历从单体应用到微服务架构的升级，项目经历了从Spring到SpringBoot的改造，配置实现自动化，初步实现分布式，微服务，具备一定的容错能力，完成RPC框架 Dubbo的定制化改造。目前，凯京科技在领域驱动方面也在不断的探索和实践，将DDD与微服务有机结合来构建系统，从而做到系统的高内聚、低耦合。

1. 为什么选择DDD:

1）、与微服务架构相得益彰（微服务是要创建一个高内聚，低耦合的服务）

2）、DDD中的界限上下文则完美匹配微服务要求，可以将该界限上下文理解为一个微服务进程，

3）、微服务架构强调从业务维度去做分治来应对系统复杂度，DDD 也具有这样的业务视角。DDD与微服务架构图：

4）、DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。

5）、微服务追求业务层的复用，设计出来的系统架构和业务一致，在技术架构上与系统模块之间充分解耦，可以*地选择合适的技术架构。去中心化地治理技术和数据，DDD个人感觉也是高度抽象封装，将其功能独立化。

2. DDD中涉及到的相关概念

1）、实体：当一个对象由其标识（而不是属性）区分时，这种对象称为实体。

2）、值对象：当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象（Value Object）.

3）、聚合根：Aggregate(聚合)是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate root）是这个聚合的根节点。

聚合是一个非常重要的概念，核心领域往往都需要用聚合来表达，其次，聚合在技术上有非常高的价值，可以知道详细设计。

聚合由根实体，值对象和实体组成。

如果聚合创建复杂，推荐使用工厂方法来屏蔽内部复杂的创建逻辑

4）、模块(Module)：是DDD中明确提到的一种控制限界上下文的手段，一般尽量用一个模块来表示一个领域的限界上下文。

5）、领域对象：具有行为，对象更加丰满，领域功能的内聚性更强，职责更加明确。领域行为封装到领域对象中，资源管理行为封装到仓库中，将外部上下文的交互行为封装到防腐层

6）、资源库：数据库

7）、防腐层：也称适配层，在一个上下文中，有时需要对外部上下文进行访问，通常会引入防腐层来对外部上下文的访问进行一次转义

8）、领域服务：串联领域对象，资源库、和防腐层等一系列领域内的对象的行为，对其他上下文提供交互的接口。

9）、DDD中数据流向图：

3. 模型概念：

领域模型并不完成业务，每个Domain Object都只完成属于自己应有的行为（Single Responsibility），领域模型是用于领域操作的，也可用于查询，查询有代价，领域驱动设计不是为多样化查询设计的；

查询是基于数据库的，所有的复杂变态查询其实都应该绕过Domain层，直接与数据库打交道；

领域模型-》Objects,数据查询-》table rows。

失血模型：基于数据库的领域设计方式其实就是典型是失血模型

贫血模型：仅用作数据载体，而没有行为和动作的领域对象（传统三层架构Action/Service/DAO,以数据为中心，以数据库ER设计作为驱动，其实际是对数据的移动、处理和实现的过程）

充血模型：在一个pojo里引入了另一个创库Repository,不是一个纯的内存对象。这个对象中隐藏了一个队数据库的操作。

领域模型：依赖注入，依赖注入在运行时是一个单例对象，只有在spring扫描范围内的对象才能通过@Autowired 用于依赖注入，通过new出来的对象是无法通过@Autowired得到注入的。

领域模型存在于内存对象里，这些对象最终都要落到数据库。

4. 设计领域模型的一般步骤：

1）、根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；

2）、进一步分析每个上下文内部、识别出哪些是实体，哪些是值对象

3）、对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；

4）、为聚合根设计仓储，并思考实体或值对象的创建方式。

5）、在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

5. 微服务架构图：

6. 微服务架构基础

DDD在凯京科技已在客户体系互联网产品和支付服务体系项目中实践，并且在业务扩张性和系统稳定性上经受了实战考验。相信在未来，会有更多的项目应用，敬请期待。

参考：

美团技术团队博客：领域驱动设计在互联网业务开发中的实践

阿里盒马：阿里盒马领域驱动设计实践

InfoQ技术分享：微服务架构技术栈选型手册

作者简介：李华。2016年5月加入凯京科技，曾任java高级工程师和项目经理，现任账务、资金、凯京支付服务体系负责人。

Tip: 公司现招聘高级JAVA工程师，欢迎你的加入，请投递简历到邮箱：lihua@keking.cn