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