背景介绍
近年来，苏宁集团业务不断扩大，用户快速增长，线上线下融合不断深入，系统的复杂性越来越高，技术的广度和深度都在不断拓展。
在整个集团技术不断迭代演进的过程中，集团内各个系统也同步更新、迭代、重构，快速适应技术的发展，满足业务增长的需求。
苏宁金融会员系统作为苏宁金融的一级系统，从易付宝诞生开始就作为基础支撑系统为整个金融业务系统提供会员服务。经过多年的演化和业务版本的迭代维护，到如今代码调用错综复杂，各个逻辑散落在代码的各个角落，牵一发而动全身。而且这些业务逻辑基本都集中落在了代码的 Biz 层中，导致 Biz 层臃肿庞大。
为了适应苏宁业务的快速发展，跟进苏宁集团多活架构的演进，金融会员系统的技术架构需要再一次跃迁。
架构选型
重构系统的架构选型是一个仁者见仁智者见智的事情，没有哪一种模式是标准答案，只能追求更适合的选项。本次对金融会员系统重构，从框架选型到架构选型都做了新的选择，选择了 Spring+Mybatis+Mycat+MySQL 的技术框架和 DDD+CQRS+ 插件的架构模式。
领域驱动设计（DDD，Domain-Driven Design）作为这一次系统重构的架构选型，主要考虑到以下因素：
DDD 模式更加关注业务领域，能够使得苏宁金融会员系统更加聚焦会员产品的核心业务。DDD 模式采用面向对象的设计，将系统模块化，有利于实现软件模块的高内聚和低耦合，使得会员系统更加适合应对苏宁业务的快速迭代。
技术实现
领域驱动设计实践
DDD 模式的最大优势在于聚焦产品核心业务，最难搞定的也在此处。那么该如何实现呢？领域驱动设计的关键在领域模型，如果把领域模型拆开来看，如下图，就不难理解了。
图 1 领域驱动设计拆分
那么，理解领域驱动设计就变成如下四点内容：
1. 精通业务
精通业务，需要业务专家，对于互联网产品，产品经理就是业务专家。技术人员作为重构发起方，需要不断和产品经理讨论业务，梳理出业务流程中隐藏的数据信息。例如会员系统的开户服务，产品经理给出的业务流程如下：
图 2 面向过程的开发模式
上面流程看似很清晰，按着常规思路，上面每一步对应一段代码，按这种方式写出来的代码，就是大家常说的面条代码（或者事务脚本）。
如果采用领域驱动设计的模式来做的话，会怎么样？首先，和产品经理讨论，..流程涉及哪些操作步骤，各个步骤涉及哪些数据；然后，将各个步骤的数据和对应的操作包装起来成为一个一个对象；最后，和产品经理讨论这些对象还应该具有哪些功能，各个业务功能模块分属于哪些对象。和产品经理的沟通不再是基于业务流程，而是基于业务模型。那么..流程应该如下图所示：
图 3 面向对象的开发模式
