作者简介
袁健，中国移动云能力中心SaaS产品部技术专家组成员，曾负责能力开放平台、云能OA门户、集中化远程交付、集中化计划建设等产品及项目的研发工作，架构设计及研发管理经验丰富，在微服务架构设计及领域驱动设计方面有较为深入的研究。
导读
随着云原生基础设施的日渐完善，微服务等架构的日渐成熟，信息化系统能够支撑的业务也越来越复杂。如果没有适当的方法，就很难对复杂的业务进行分析与实现，云原生基础设施与架构的效能也很难充分体现。领域驱动设计就是这样的一种思想，它可以指导研发团队更好的进行业务分析与规划，高效高质的提炼领域模型，用领域模型指导架构设计和研发实现。
一、微服务不是银弹
1、微服务架构的难点
云原生时代微服务架构由于高扩展性、高容错性、高可用性以及快捷交付的优势，得到广泛的应用。但是微服务架构对研发团队也存在拆分难、治理难的困扰。微服务拆不好，影响系统的后续扩展与实际运行，微服务的优势得不到体现。微服务治理不好，影响微服务的运行与后期运维。
2、难点应对措施
目前微服务治理工具发展较为完善，不管从框架层面还是基础设施层面都有很好的解决方案。相对于微服务治理，微服务拆分没有实体工具来支撑，更多的是需要设计人员的自身能力，不但需要对业务有很好理解，还需要有一定的技术功底，更需要有科学方法论的加持。但是，往往负责微服务拆分的设计人员都缺少科学方法论的支撑，领域驱动设计思想正好能弥补这一方面的空缺。
二、完善的设计思想-领域驱动设计
1、什么是领域驱动设计
领域驱动设计不是架构方法，也不是设计模式，就是一种思维方式（在此基础上延伸出了一些方法论），通过领域驱动设计这种思维方式，定义领域模型，从而确定业务边界和应用边界，保证业务模型和代码模型的一致性。
很多读者因为其复杂的理论而认为领域驱动设计只适用于复杂系统或者是微服务架构的系统。这是认识上的误区，由于整套理论的目的之一是解决设计与研发脱节的问题，因此对于简单业务或者单体系统也同样适用。
2、领域驱动思想的由来与发展
领域驱动设计思想首先是Eric Evans提出来的，后来又由Jimmy Nilsson等人不断的充实和丰富。当前这个思想不是一蹴而就的，在他之前Martin Fower先提出了技术架构领域的设计模式思想。
• 2002年Martin Fower在其出版《企业应用架构模式》中，归纳总结了40多种企业应用架构的设计模式。其中所提到的多种设计模式和概念，如事务脚本、活动记录和领域模型等，对业界产生了深远的影响。
• 2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍：《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文译名：领域驱动设计—软件核心复杂性应对之道），书中提出了“领域驱动设计(简称DDD)”的概念。
• 此后Jimmy Nilsson的《Applying Domain-Driven Design and Patterns》、Abel Avram和Floyd Marinescu合作的《Domain-Driven Design Quickly》、Dan Haywood的《Domain-Driven Design Using Naked Objects》、以及Vaughn Vernon的《Implementing Domain-Driven Design》等书籍的出版，丰富了领域驱动设计的实践和指导。
领域驱动设计思想基于架构设计模式，相辅相成，互为补充。Martin Fower的架构设计模式主要是技术架构的设计方法论。而Eric Evans的领域驱动设计填补了业务领域设计的空白，并且为业务设计到技术设计的衔接起到了重要的指导作用，Eric Evans提出领域驱动思想的一个重要目的之一就是希望业务架构设计人员不能和一线研发人员脱节，要不断接收研发的反馈，不断的迭代业务架构的设计，使设计真正的能够落地。
3、领域驱动设计的过程
领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析，建模，架构，设计以及最终的编码实现。大致可以分为两个阶段，战略设计和战术设计。所谓战略设计，可以简单理解为粗粒度设计，即领域的划分。所谓战术设计，可以简单理解为细粒度的设计，采用模型驱动设计方法对各领域分而治之，不涉及技术层面的细节但对研发具有指导意义。
领域驱动设计过程是一个演进的过程，战略设计控制和分解战术设计的边界与粒度，战术设计则以实证角度验证领域模型的有效性、完整性与一致性，进而以演进的方式对之前的战略设计阶段进行迭代，从而形成一种螺旋式上升的迭代设计过程，两个不同阶段的设计目标是保持一致的，它们是一个连贯的过程，彼此之间又相互指导与规范，并最终保证一个有效的领域模型和一个富有表达力的实现同时演进，如下图所示：
三、领域驱动设计思想的微服务实践案例
1、实践案例介绍
1.1、实践案例背景及目标
随着中国移动战略转型，计划建设领域的项目管理办法逐渐完善及各省信息化系统的逐步实施，导致当前计划建设管理系统为集团与省公司两级平台的建设方式，存在管理方式不统一，精细化管理水平差异大，数据标准化和互通流转不畅,嵌入式风险管理薄弱等问题，已不能满足日益提高的项目管理要求，亟待建设集中化的计划建设管理系统，以达到规范各省项目管理流程、统一数据规范、防范生产及管理风险等目的。
基于上述背景，中国移动集团启动了集中化计划建设系统的研发工作。集中化计划建设管理系统是一个融管理, 业务, 架构于一体的管理系统，实现了计划建设领域全生命周期流程覆盖、全专业支撑，要求做到管理一体化、业务一体化以及架构一体化。
1.2、项目研发存在诸多困难与挑战
集中化计划建设系统由于需要在管理、业务以及架构三个维度对全国各省各专业公司已有系统及数据进行统一管理，因此在这三个维度分别存在巨大的困难与挑战。
• 业务维度：随着业务持续演进，业务复杂度越来越高，业务要求的响应速度也越来越快。
• 技术维度：流程数量较多，流程设计、变更频次高，对平台易用性及扩展性要求越来越高；接口交互调用频次高，对性能及稳定性要求较高；分布式部署环境复杂，需要同时支持集中监控及分域管理。
• 管理维度：跨系统间协作，参与单位多，涉及的人员多，管理复杂度高；流程数量较多，流程发布、变更、下线等管理复杂度高。
针对以上三个维度的困难，在架构及业务领域设计上分别采用了先进的微服务+PaaS的架构模式和领域驱动设计思想。
1.3、采用微服务+PaaS技术架构
系统包括多个独立自治的子模块、对于系统可扩展性、容错率等要求较高，这些要求与微服务架构的优点不谋而合；同时由于其对接系统多、体量大、资源维护难度大，若采用传统管理模式势必带来资源难以管控等问题，因此采用PaaS平台化的管理模式进行资源及能力统一管控，有利于实现系统弹性扩展能力。
1.4、采用领域驱动设计解决业务复杂问题
由于计划建设管理系统目标是建设全国集中的、服务一线生产与管理的系统，并且能够达到规范各单位项目管理流程、统一数据规范、防范生产及管理风险等目的，实现计划建设领域全生命周期流程覆盖，全专业支撑，内部及外部用户全员使用，因此业务逻辑非常复杂。
系统整体业务复杂，从投资计划到项目归档贯穿资产管理全生命周期，没有科学的业务分析方法，很难做到业务的细化拆解，实现高内聚低耦合的目标，项目团队通过深入调研和对比，最终决定采用领域驱动设计思想解决目前面临的业务复杂、微服务拆解困难的问题。
2、基于领域驱动设计思路的微服务落地
项目整体采用领域驱动设计思想。领域驱动设计是自顶向下的设计方法，先在业务期望明确的基础上进行战略设计，再进行战术设计。战略设计从宏观角度来观察和审视软件系统，战术设计将战略设计进行具体化和细节化，侧重于技术实现。统一语言的建立贯穿整个项目研发的始终。
2.1、项目团队领域驱动设计实践概览及团队协作关系
项目团队在领域专家的带领下通过对行业最佳实践的学习以及对PMS现状诊断及业务期望的分析，梳理系统全景业务流程并对流程进行业务边界的划分。基于业务边界，依据康威定律划分团队，各团队由领域专家和研发组成，每个团队在各自的业务领域进行分析与设计，团队间协作关系由项目经理进行协调。架构师在领域专家配合下，在技术实现层面进行微服务设计指导研发编码实现。
2.2、系统的顶层价值设计
2.2.1、业务期望分析与明确
分析系统的业务期望，首先需要分析系统的相关干系人，对干系人进行归纳，分析他们对系统的期望。借助业务需求和管理关注点分析模型，发现并汇总集团、省分、地市不同关注者的关注点和问题，明确各环 节投资与建设目标。
组织干系人进行头脑风暴，以便干系人对业务系统期望达成一致。在设计过程中，团队成员对于愿景的输入相对较少，潜在原因是前期未达成共识，讨论思想较少，目标系统 知识缺乏，主要通过目标系统归口部门完成相关的信息输入。
2.2.2、统一语言的建立
为了统一所有领域公共概念的表达形式，项目组在开始进行领域分析之前，先把全局概念进行定义，为战略设计阶段的分析奠定沟通基础。所有领域专家与研发团队分别从计划建设主流程的资金管理和项目管理两条线进行梳理，从全局角度提炼统一语言。首先梳理了67条核心业务概念，待后续领域划分好之后，各个领域团队再逐步细化与定义各自的领域术语，进行领域内表达方式的统一。
2.3、战略设计阶段
2.3.1、业务全景分析
进入战略设计阶段，基于事件风暴分析方法，以领域专家为主导，大家从项目前期、项目实施以及项目收尾三个阶段，梳理了从需求规划到项目结束，包含72个核心事件的全景业务流程。为进一步领域划分展示了清晰的全景视图。
事件风暴是一种高度强调交流与协作的可视化工作坊，在分析过程汇总，重点寻找业务流程中产生的领域事件，探索出业务全景。基于业务全景以及事件表达的业务概念，就可以对领域进行划分，确定子领域和限界上下文。
2.3.2、领域分析与微服务划分
基于业务全景图，领域专家和研发团队对系统业务场景分三个阶段（项目前期、项目实施以及项目收尾）进行领域分析与划分。通过识别限界上下文，聚焦核心领域，以项目前期阶段3个核心领域，项目实施阶段3个核心领域以及项目收尾阶段4个核心领域为中心进行分析，划分出15个业务域，并通过上下文映射建立它们之间的关系。最后，基于核心业务领域的划分，领域专家与技术专家进一步分析支撑核心领域的技术能力及非核心领域功能，在核心领域基础上扩展出20个领域，最终基于领域划分20个微服务。同时领域专家和研发团队按微服务分成20个研发小组，一个微服务团队领域专家和技术专家各一名。
2.4、战术设计阶段
在完成微服务划分之后，项目组进入单个微服务的详细设计阶段。20个微服务按组分别进行领域模型分析，整个分析过程借鉴了事件风暴和领域模型驱动设计的方法，先对领域进行事件分析，然后细分领域，进行领域内模块的划分，最后对领域模型进行建模，指导研发工程师进行程序的研发。期间随着领域模型分析的不断深入，各微服务的模型也不断进行迭代与重构。
其中以物资微服务为例，通过分析划分出8个模块（基础数据、项目领料、物资接收、物料平衡、现场物资、现场物资调拨、项目退料和库存查询），然后分别对每个模块进行建模，指导研发工程师建立ER关系图。
整个建模过程围绕业务需求，分析与提炼领业务需求中的领域知识。为了避免受技术的干扰，完全表达业务的逻辑关系，建模过程由领域专家主导，在领域专家指导审核下，模型由研发团队创建，保证模型的顺利落地，业务与技术不脱节。
总结
领域驱动设计的核心是化繁为简，思想上有其普适性，方法上有其特殊性。实现上大概可以概括为，先以分层架构突出业务领域，再以模型驱动的方法把业务进行领域划分，最后细分模型指导架构设计与研发实现。在实际研发过程中应该合理采用领域驱动设计思想，扬长避短，灵活运用。
随着信息化程度的日益增高，业务和技术已深度融合。在业务对技术的要求不断提高的同时，技术对业务的要求也在不断提升。没有好的业务架构设计，要设计好技术架构就会很存在很大的局限性。在业务分析阶段应优先考虑领域问题，只有在业务分析透彻的基础上，才能设计出高内聚低耦合、扩展性良好的技术架构。 
