一、概述

学习DDD也一段时间了，阅读过许多相关的文章，但是一直给我一种云里雾里的感觉。一方面大部分文章都是在讲DDD的概念，并没有实际的例子，导致难以理解；另一方面DDD与传统的数据库建模相差较大，对以往的开发方式冲击较大，导致无从下手。

本文尝试使用DDD来介绍有赞信贷核心系统的设计过程，让大家对DDD的落地有一定的了解。由于本文主要讲解设计过程，因此不会展开讲DDD的基本概念，希望读者对于DDD的相关概念已经有一定的了解。

二、DDD简介

DDD是一种方法论，贯穿了整个软件开发的生命周期。是为了解决某个领域的特定问题，从复杂的现实世界中抽象提炼出业务模型的思维方式与实践技巧。使用DDD实际运用的是分治的概念，把大的复杂业务分解成一个一个小领域，然后从小领域切入去解决问题。DDD的目标就是将业务边界划分清晰。

DDD主要分为两个部分，战略设计与战术设计，战略设计围绕微服务拆分，战术设计围绕微服务落地。

三、有赞信贷核心系统实践

3.1业务流程梳理

当我们拿到一个实现信贷核心系统的需求时，首先我们要建立对应的领域知识。那我们如何去获取呢？比较有效的方式就是找领域专家，专家可以是这个领域的专家或者产品、运营都可以。目的是在与之沟通中理清业务流程，抽象必要的领域元素。

我们以借款流程为例，假设通过以上方法我们梳理出了信贷核心的借款流程。用户提出借款申请，风控运营人员审批通过后，系统扣减对应的用户额度，之后用户签署借款合同，系统生成对应的还款计划并放款到用户的账户。其流程大致如下：

3.2四色建模

领域建模有很多种方法，我们本次选用四色建模法。

首选我们从业务流程中尝试寻找时标对象（用红色表示），可以认为是核心业务单据。此类对象是发生的事实，当出现问题的时候可以追溯。我们从上述业务流程可以分析得出，借款申请对应借款单，借款审批对应审批单据，额度扣减对应额度扣减记录，签署合同对应签约记录，生成还款计划对应账单，放款对应支付单。在找到时标对象后尝试寻找参与方（用绿色表示），一般可以是人、物、地点等。这里参与方包含风控运营、额度账户、资金账户、合同等。之后再分析参与方是以什么角色参与到业务流程中的（用黄色表示），风控运营是以审批人角色参与到业务中的。最后尝试给参与方添加一些描述信息（用蓝色表示），使其更具象。根据上述方法画图如下：

3.3划分领域

四色建模完成后，我们就可以开始进行领域划分，确认限界上下文。从时标对象入手划分如下：

3.4详细设计

至此一个借款流程的领域模型就拆分成了一些小的领域，现在开始可以针对每个领域逐一进行详细设计。我们可以借助用例图、流程图等。

3.4.1 用例图

用例图主要用来描述参与者与用例之间的交互，用例与用例之间的关系及系统的边界。说明的是谁使用系统，以及使用系统干什么事情。我们以借款为例，用例图如下：

3.4.2 流程图

流程图帮助我们把一个复杂的过程简单而直观地展示出来。活动图、状态机图、序列图是流程视图中最重要的三种视图。三者侧重点有所不同：活动图侧重于逻辑分支，序列图侧重于交互，状态机图侧重于状态流转。我们这里不一一展示每种图的用法，仅挑选序列图简单展示如下：

3.5 分层架构

在设计完成后就开始进入代码落地阶段，落地前需要确认好系统分层。分层的目的是使其结构清晰，便于后期维护。一般分层架构分为严格和松散两种。区别是严格分层只与其直接下层发生耦合，而松散分层是允许任意下层发生耦合。DDD有三种比较经典的分层架构，四层架构、五层架构和六边形架构。六边形架构通过适配器的方式与外部交互，将应用与领域模型封装在系统内部。保证核心领域不受外部干扰的同时,端口的可替换性也可以很方便的对接外部系统。其架构图如下：

四、结语

至此DDD在有赞信贷核心系统中的实践就结束了。本文提供了一个大致的设计思路，希望能给大家在使用DDD的时候带来一些帮助。同时需要提醒各位DDD更适合大型的复杂业务，对于业务模型相对简单的，反而会提升设计复杂度。