背景介绍
我们是CRO面向商家的业务技术团队，做商家营商环境治理业务已经4年了。作为垂直型业务技术团体（区别于平台技术团队），我们也面临大部分业务技术团队的拷问：业务技术与平台技术的差别是什么？业务技术如何做？如何理解业务？如何在短频快的业务节奏中做好技术？部分问题有答案；部分依然在寻找更好的答案。本文是对过去四年的总结：从业务&技术两个角度提炼出一个基础思维框架，供业务线开发同学参考。
- 业务视角：业务驱动技术是前台业务的特点，业务开发要逐渐培养自己全局视角看业务的能力：从交付价值角度理解业务模式；从能力规划角度掌握产品方向。本文的第一部分介绍价值引领业务架构的做法
- 技术视角：应用架构的内容很大，本文第二部分介绍了架构设计的两种方法（风格），以及域划分和流程建模两个架构关注点
业务架构
业务架构目的
业务架构范围比较大，本文借用“业务架构”这个词想讲的内容是：业务开发应该如何关注&分析业务问题；如何理解业务以及指导系统设计
业务架构做什么
业务架构最重要的是"看全局"（每个人立场/角度/高度不同，对“全局”的理解不同)，这里强调的是：向外看的意识，而不是如何看的方法。从三个点出发看全局：
- 看清楚 "事"：从宏观角度看“事”是价值源点，是业务战略&目标&价值；从微观来看“事”是业务流程。看清楚"事"就理解了“为什么做”和“怎么做”的2个核心问题。以我们做的业务为例：宏观的"事"就是帮助商家低成本处理风险问题，降低商家经营成本，提高平台竞争力；微观的“事”包括了商家风险预警流程，风险反馈流程等。看的阶段尽量脱离具体系统/业务，向高度和广度拓展视野。以风险预警为例：从广度上看，风险是如何识别的（有哪些上游），如何透出的（需要什么内容），怎么触达商家；从高度上看，有多少种风险可以预警（共性是什么），商家怎么处理（成本如何等），是否有更优的处理方式。
- 理清楚 "人"： 谁（利益相关者）一起做这件“事”。对利益相关者进行分类管理，识别用户的不同诉求，排序优先级。关键点是用户要什么（用户视角的，而不是外部视角）。
- 分清楚 "责"： 不同"人“的权&责，在流程中的角色。从产品建设角度出发，人&权&责的识别为了深入了解用户诉求，设计产品能力。例如商家产品需要考虑商家不同角色员工的权&责，以及不同角色需要的产品功能。
业务架构怎么做
看清楚事-价值流/能力映射
价值流: 价值流是从利益相关者（客户、最终用户或工作所产生的产品、服务或交付品的接收者）的视角来描述描述一个端到端价值交付的完整过程。业务能力: 业务能力是业务为实现特定目的或结果而可能拥有或交换的特定能力或产能能力/价值流映射: 将业务能力映射到价值流中的每个阶段的过程，用于突出哪些能力对业务运营有着或大或小的重要性
分析价值流有助于从更宏观视角理解业务全过程：价值交付过程拆解成若干阶段，由不同的角色协作完成；每个阶段需要不同的能力。通过分析能力现状（完备，缺失，部分满足），评估价值&紧迫度，可以对未来规划形成构思。下图是Togaf招聘员工价值流的示例图，该图描述了招聘员工的完整流程和产品能力诉求，通过颜色区分不同能力的现状（绿色代表满足诉求；黄色代表部分满足；红色代表能力缺失）。
理清楚人&责-角色分析
使用UML用例图描述业务中的"人"和责。营商业务里有3种角色，各角色责任如下图展示
有了全局的人&责概览后，通过分析特定场景工作模式可以发现需求，问题或解决机会。这里的转变是：不只关注当前单个需求，而是从全局视角看业务诉求，从而对需求的合理性，重要性有更合理的判断；为设计方案提供业务视角考虑。例如下图例子描述员工招聘的工作模式。(从中可以看出入职阶段有提升较大空间）
应用架构
架构：组件的结构、它们之间的相互关系，以及关于组件设计和随时间演变的原则和指南。架构做的事情主要是：识别组件，定义关系，确定原则。组件和设计视角相关，不同视角下组件的形式/粒度:
- DDD：子域就是组件，域之间的关系，域设计原则
- 流程视角：流程，子流程，阶段都是组件；定义不同粒度下组件的交互关系和原则
- 数据视角：数据表是组件，表之间的关系，和设计原则（范式和反范式）
- 架构分层：层是组件，分层交互的关系和原则
- ....
本文将介绍两种通用设计方法（自上而下，自下而上），以及领域建模和流程建模的相关知识。
架构方法
自上而下
自上而下设计是指参考标准方案，裁剪/适配形特定解决方案的过程。很多业务域已有标准模型或解决方案（例如财务域，电商，供应链等），这些业务域采用自上而下方法是一个不错的选择。设计师经验丰富/知识面广适合采用该方法；当然如果设计师经验不足，也可主动调研后实践。在大部分业务自上而下方法使用不多，不详细展开。
自下而上
自上而下设计是指从具体的业务细节出发，分析归纳最后得出解决方案的过程。自下而上是我们在日常业务中经常使用的方法，本文重点介绍如何做自下而上的设计。
自下而上"三板斧"
我们从实践总结出自下而上设计的"三板斧"，作为框架指导设计过程：
第一招：自下而上做归纳
分析问题空间，通过归纳分类减少复杂度。分为两个过程：场景梳理 和 场景分类
- 场景梳理：罗列所有问题细节。例如：流程建模先罗列所有子流程；领域建模先罗列所有域内概念
- 场景分类：划分类型，合并同类项。找准分类是对问题空间信息的提炼，有些分类很容易；有些分类的识别需要一个迭代过程：
- 先根据经验或直觉选主要的划分维度，识别类型
- 将场景归入对应分类
- 遇到难以归纳的场景，则评估是否需调整分类
第二招：抽象分析出设计
所谓方案是解决方案空间里的解法，设计过程就是就是从问题空间过渡到解决方案空间。这是过程中的难点，也是最困难的点。设计结果视目标而定（有时是领域模型；有时是流程框架等），使用的方法也需结合问题而定。
第三招：自上而下验场景
设计方案要放在设计场景里进行"推演"。推演的过程很重要：既要推演已知的场景，评估是否满足现有需求；也要对可能性高的未来场景进行推演，评估未来的适应性。
架构实践
领域建模
本文不赘述领域建模的具体方法，只讨论下“子域划分”的问题。虽然有很多文章介绍子域识别的方法，对域划分还是比较难掌握的。如果你见到在某个业务应用里划分5+子域，有些子域里只有少数几个对象或方法，不要觉得奇怪，这些子域很可能是模仿教课书方法的产物；也可能是拍脑袋得到（常见情况），很多域都是"凭感觉"划分的（例如很多应用都有“配置域”）。看个例子：下图的领域模型能找到清晰的子域边界吗？在模型中找出连线少部分画分界线，两边连线越少说明边界越清晰。下图很难找出清晰且适合边界，但是设计方案里分了4个子域，这样的域划分是值得推敲的。（PS:看图说话是领域划分里一个直观好用的方法）
域的目的
回到域划分的初衷：域划分的目的。域划分和维护是有成本的（成本不低），付出了成本就要考虑收益，域划分的目的（即收益）到底是什么？我认为最重要的有两点：
- 控制复杂度：生活中通常将复杂大问题划分为若干个容易解决的小问题。DDD的战略工具“子域”就是控制复杂度的工具：核心域，通用域，支持域就是划整体为部分，降低复杂度的具体方式。
- 提升复用性：DDD子域类型里"通用域"的概念，清晰表明域的可复用性。
域划分的设计原则，我的观点是：非必要不划分；无收益不划分；不确定不划分。域划分一定要有收益：要么是复杂度降低；要么是复用性提升；要么两者都有。如果没有收益或收益过少，就不要划分子域。在实践中域划分错误的两种"坏味道"：
- 域很浅: 域划分很细，每个域少数几个对象，通常是问题不复杂，不需要划分。
- 域边界模糊：领域对象关系复杂，子域间没有清晰边界，暗示了模型关系错误或者子域划分错误。
域的识别
虽然有很多的方法帮助识别子域，最主要的还是靠实践摸索，从正反两个方向迭代设计：
- 正方向：从各种特征/方法出发识别可能的域 (域划分包括：从域定义出发/参考已有标准方案/识别领域概念模糊性/四色建模/事件风暴等）；
- 反方向：通过域设计原则和收益验证划分的合理性；
域的验证
域设计原则以星环总结的"自治单元"最为完备，实操性较好。
领域自治与设计原则高内聚低耦合是一致的，核心判断点：
- 最小完备&自我履行 看 "依赖" : 域的价值主张决定了域职责，域内包含了完成职责所需要的必要信息以及能独立作出决策，不/少依赖外部域。举例来说：在业务系统设计里经常看到运行域和配置域的设计；运行域执行任何功能都依赖配置域信息。那么从域的完备性和自我履行角度考虑，这种拆分是不合适的。
- 稳定空间&独立进化 看 "变化"：稳定空间是当前域不受/少受外部域变化的影响；独立进化是指域内变化对外部域没有影响/影响较小。举例来说，子域A直接引用了子域B的领域对象C，对象C变化一定影响到子域A；这种情况说明领域A不够稳定；或者说领域B不能保持独立进化。
流程建模
流程设计问题
以DDD四层模式为例：领域层模型设计逐渐得到了重视；但是应用层设计没有得到足够重视。通常讲应用层职责是面向用例组织业务流程，在实际代码实现中能发现非常多的应用层混乱导致的代码复杂度提升，典型问题包括：阶段粒度不一；节点职责不清；交互混乱。出现这些问题根源是业务逻辑是围绕“数据中心”组织的，没有对流程进行仔细的设计和组织。
流程建模做什么
这里的“流程建模”特指业务逻辑处理的组织方式。流程建模三件事： 定阶段，定职责，定交互。
- 定阶段
这里的“阶段”和"流程节点/处理节点”等概念类似，定阶段就是设计业务场景下程序处理步骤，包含业务和技术考虑。阶段是设计出来的传达出的观点是：根据设计目的（性能/灵活性/结构清晰等)，阶段的粒度/顺序是有选择空间。注意：同类型流程的阶段划分粒度保持一致。同类型理解为类似场景，举例来说消息处理场景，那么不同类型消息（创建/完结/撤销等）的处理流程的阶段粒度保持一致。
- 定职责
定义每个阶段的职责范围。在设计里（无论域识别/应用分层等粗粒度还是类/方法等细粒度设计），职责定义都很重要：明确了职责本质上定义了边界。这样每种功能的实现位置做好了设计，减少了随意性，有利于架构整体的清晰性，不至于腐化成大泥球。
- 定交互
流程间&流程内的调用关系。请看下图示例的执行过程（这是从真实代码还原出来的）：节点A调用了扩展点，扩展点执行完成后调用了节点B. 大家先想一想这样合理吗？
在生活中同层级机构对话、机构内上下交流、机构间同职级交流；很少有低层级员工直接和外部机构的领导对话。这是我们的生活经验，流程交互设计的原则也是类似的，节点负责组织该阶段内的执行逻辑，完成后通知下一个节点。这种节点交互原则总结为：阶段内上下对话，阶段间水平对话。
流程建模怎么做
自下而上流程建模简化为穷举->归纳->推演三步骤，每一步都可以若干次迭代完善。
- 穷举: 选择熟练的工具梳理流程（流程图，ES等都可以），建议是：按业务场景类型梳理，一次可以梳理一个或几个场景，分多次完成。
- 归纳："通看"场景，找共性、找差异、找设计点，采用"合，增，调"(合并同类节点；增加缺失节点；调整节点顺序)三技巧完成流程设计。如何“调顺序"要看设计目的，例如性能优先将部分业务校验节点调整到前面。
- 推演：用步骤2设计的流程推演业务，主要评估执行顺序和节点职责是满足业务需求。
实例练习
自下而上流程建模
使用自下而上方法为员工入职跟踪流程建模：首先由HR录入待入职员工个人信息和资料，确认无误后为员工分配办公空间；随后系统为员工准备资产和开通账号&权限；员工领取到资产，登录账号后，入职流程就完成了
第一步 自下而上做归纳
由上文的价值流热力图，我们知道公司的入职跟踪流程亟待建设：入职跟踪和员工信息管理能力缺乏；资产管理&设施管理&安全管理有基础能力，但是需要提升。本次使用了事件风暴方法，业务，产品和研发一起梳理入职跟踪过程，目的是建设入职跟踪能力。
第二步 抽象分析出设计
员工入职跟踪接收来自信息管理系统，资产管理系统，安全管理系统的事件，更新入职进展。设计后的流程模型如下图。增加了技术节点: 消息解析，校验，协议适配；为保持流程清晰性，将判断是否"首次流入"的节点提前到了协议适配前执行。
第三步 自上而下验场景
推演是将业务执行过程，用流程表达出来；场景推演技术特别适合复杂业务的验证，能发现设计阶段的遗漏点。下图推演员工已报到事件的处理流程。
总结
本文提供一种业务架构设计模式供大家参考。整个框架希望表达2个重点：1 首先要有业务视角思考，突破仅关注需求实现设计，而是从业务价值出发的业务架构思维；2. 强调设计的逻辑：自上而下或自上而下都是强调设计过程，每个设计决策需要经过推演得出。
作者 | 李建(甫田)
来源 | 阿里云开发者公众号
