共计 5176 个字符，预计需要花费 13 分钟才能阅读完成。
简介：首次上线利用，面对业务框架搭建你是否曾感到无从下手？保护线上利用，面对大量历史包袱你是否正避坑不迭深陷泥潭？为何同样是业务利用，不同人的设计格调千差万别？为何最后的设计通过多个迭代后总是面目全非？新人来到团队，怎样才能疾速理解业务，不被大量技术细节折磨？如果你也有这些困扰，心愿本文能提供些许帮忙。
作者 | 木沉
起源 | 阿里技术公众号
首次上线利用，面对业务框架搭建你是否曾感到无从下手？保护线上利用，面对大量历史包袱你是否正避坑不迭深陷泥潭？为何同样是业务利用，不同人的设计格调千差万别？为何最后的设计通过多个迭代后总是面目全非？新人来到团队，怎样才能疾速理解业务，不被大量技术细节折磨？如果你也有这些困扰，心愿本文能提供些许帮忙。
一 初衷
1 细节割裂架构
业界的成熟利用框架有很多。无论是 SpringMVC/SpringBoot 还是 SofaBoot，都对工程构造给出了明确的标准约定，职责边界看似十分清晰。但在实践中，再简略的业务利用都防止不了业务逻辑扩散各处，突破 module 边界呈现隐式耦合的景象。扩散的业务细节必然导致利用架构的割裂，如果没有继续的重构调整，最终总会变得复杂臃肿（当然，是继续有新需要的前提下），老人缄默新人流泪，只能依附天降猛男重做 2.0。究其原因，集体认为次要在于：
框架灵活性过高：利用框架给出的是工程标准，而非业务设计规范，为开发者保留了十分大的灵活性，一个业务性能能够有很多种实现形式。
架构约束力有余：业务架构的搭建和保护是在不同时段由不同人别离投入的后果，设计思维的不同，自我要求的不同，我的项目进度压力的不同，都会对利用的现状产生影响。
若以法律和道德的关系做类比，通用框架束缚了技术编码的“法律”底线，而设计准则就是开发人员对本身的“道德”要求。在简略的业务场景下，满足需要是第一优先级，设计能力的诉求并不突出。但在多方合作的业务团队下（真实情况大多如此），没有对立的“道德规范”，将很难造成合力实现简单我的项目。《Java 开发手册》（阿里巴巴 Java 开发规约）在推动编码标准的路线上迈出了很大一步，极大晋升了工程人员的业余素质，大大提高了“道德共识”。那么在业务架构设计的畛域里，是否至多能在某个问题域内，也建设一套面向业务研发同学的“设计规约”。
2 技术积淀散失
另一方面，进入阿里巴巴后，本身研发经验尽管并不多，但接触过不少优良设计。这些产出无论是否最优计划，都体现出了技术同学对优良设计的美好愿望和弱小落地能力，也的确在肯定的历史期间内高效地保障了业务倒退。然而，令我困惑的是，只管每个业务我的项目和业务产品都能积淀出一些可复用的组件或框架，参加研发的同学也能总结出一套面向未来需要的设计准则和实践经验，但这些财产始终难以保护和传承。可能的起因有（对前端 / 测试 / 数据 / 平台等研发经验不太理解，这里仅针对一线业务研发）：
保持设计成绩而非设计准则：有成功经验的研发同学，偏向于用已经的架构设计来套用当下的业务场景。这种思路自身没有对错，但如果钉不配锤，往往会在短期内引入大量额定老本，反倒丢失了本来的设计劣势。面对具体问题域，只有保持一贯的设计准则，在需要剖析的过程中联合诸多因素进行动静衡量，能力打造真正合乎当下和将来需要的设计。
喜爱造新轮子而非继续重构：研发同学的设计准则和代码洁癖可能是一种“玄学”，对前人代码的不待见倒是更具确定性的常态，其实这不难理解。即便都是 DDD 流派，计划沟通时也未必相互认可；即便通过退让对架构设计达成统一，编码实现的格调也是各领风骚。了解前人的设计思路和代码嗜好更重要，还是按时实现业务需要更重要？按本人善于的设计格调重写更简略，还是在别人的“过期”设计上继续重构优化更简略？
靠文档传承而非工具化复用：对新人来说，文档里的再多倡议和疾速上手指南，都比不上一个开箱即用的工程 DEMO；在成熟利用上继续开发的人，不会因为历史文档上大写的注意事项就抵制住长期代码换取早点上班的事实引诱，除非利用工程中有编译 / 部署失败的强制束缚让你不得不放弃。
相比于短少“设计规约”导致的低效合作，曾经积淀的“规约原型”被轻易摈弃更加令人惋惜。业务研发的日常工作，实质上是拆解问题域的复杂性，用分层解耦 / 工具化 / 平台化 / 业务形象的多种思路将子问题一一击破。如果局部子问题已被很好解决，为何不站在前人肩上？放弃造不造新“轮子”的纠结心态吧，或者咱们更须要搭“积木”的心态。
二 思路：业务架构设计规约
联合蚂蚁链 - 利用技术团队近年来的技术实际，咱们试图从本身需要登程，搭建一套或者能满足更多业务场景的业务架构设计规约。重点阐明下，本文是从无限的问题域登程提出的解决思路，不奢求成为通用解决方案。如果其余业务线也有相似的痛点，心愿能有些许借鉴。
规范：对立业务设计框架，用标准化架构简化技术细节
积淀：从业务场景中继续积淀“积木”
重构：继续重构“积木”，缩小反复建设
集成：基于业务服务编排引擎疾速集成
1 规范——缩小细节
现实状况下，业务技术只需关注领域建模，但事实中却不得不思考更多通用的技术细节。以供应链金融场景下简化版的应收账款发行流程为例，须要思考的有：
领域建模：应收账款畛域模型及其行为的设计
流程编排：流程模型的设计及发行流程的状态机设计
数据转换：畛域模型 <-> 数据模型及流程模型 <-> 数据模型的双向转换
并发管制：业务锁机制的设计
业务幂等：流程中各业务环节的幂等管制
异样解决：异样捕获，错误码约定
监控报警：摘要日志，异样日志，边界日志
其余
在以上未齐全列举的几项中，除了“领域建模”以外，根本都是与具体业务无关，但对于一个稳固牢靠的业务利用不可缺失的局部。如果能建设一套标准化的框架计划，用对立的标准解决掉业务无关的大量细节，是否就能让业务技术同学真正的专一于“领域建模”？
2 积淀——能力复用
积淀和复用是技术群最常出圈的几个词，可见认同度之高。能力复用不局限于模式和粒度，可能切实升高技术老本，进步业务扩展性，就是不错的积淀，可作为“积木”供后续应用。以蚂蚁链利用技术团队场景为例，近年来积淀的能力包含但不局限于：
技术类
工程标准系列：束缚编码标准和边界接口定义格调，日志打印，异样解决，仓储行为，状态机等等
读写拆散机制：屏蔽交易类需要与查问类需要对数据模型的设计抵触，升高设计复杂性，晋升查问性能和灵活性
业务类
网银核身：进步网银核身签名在不同业务流程中的扩展性
合约上链：进步智能合约对接在不同业务流程中的扩展性
平台类
配置核心：灵便定义和治理业务流程须要的各类配置项
产品核心：平台性能打包和隔离，实现业务流程的全局视图
3 重构——继续优化
积淀来源于业务需要，却经常落后于新需要。对于设计者以外的人来说，保护别人的“积木”经常会踩到不少坑，反倒不如本人重写。这也是为何每个团队都在说积淀，但可能横向复用，甚至在同一个团队内继续复用的能力都少之又少。尽管这个景象没有完满解法，但集体倡议采取以踊跃的心态对待这些“积木”：
剖析历史背景，理解“积木”呈现的技术和业务背景
明确该能力可能解决的问题，和不实用的场景
剖析当下业务需要，是否能够重构该能力后间接复用
与创作者沟通，评估重构落地计划
这里没有强调重构复用和重写这两种计划的 ROI 比照，是因为集体看来，即便前者老本更高，重构的过程对集体技术成长和团队文化对立都是无利的。绝对于一直颠覆和创造新“积木”，继续优化的过程，是对本人和别人教训的一直回顾和反思，看清历史的坑，能力防止新危险的呈现。
4 集成——灵便搭建
规范可能落地，除了有足够趁手的“积木”库外，更重要的一点，是要有灵便便捷的“粘合剂”，以实现业务性能的疾速搭建和灵便调整。在供应链金融的场景下，业务需要次要体现为各种各样的业务流程，比方发行 / 转让 / 清分等等。为了简化“积木”搭建，灵便复用底层能力，咱们基于以下指标，设计了面向业务的服务编排引擎：
标准化：遵循设计规约，将业务无关的通用技术细节屏蔽
插件化：对“积木”敌对，可继续积淀和复用新能力
业务化：面向业务，有业务形容能力的流程编排
配置化：通过配置即可实现流程编排，最好能做到可视化配置
5 产品——业务大图
“积木”+“粘合”可能满足技术落地的低成本高扩大，但从业务视角，还须要一个全局大图来描述业务线的全域能力和性能流程。本文中暂不波及。
三 实际——业务架构规范计划
如前所说，只靠文档造成的共识，对技术没有足够的束缚，极难维持。因而，咱们基于上述规约的各项准则，搭建了一套标准化的业务架构设计计划，通过组件化工具化的形式束缚业务利用，造成团队共识。一个规范的业务利用架构如下：
1 组件——标准技术细节
通过组件化约定，束缚通用技术细节的行为，包含但不局限于：
交易模型
形容业务流程的外围交易模型，用于管控状态推动，维持与业务模型的关联。
仓储行为
数据长久层的通用行为，包含锁定查问 / 插入 / 更新 / 一般查问等。
事务模板
定义事务边界，确保模版内业务逻辑的事务一致性；反对幂等能力。
通用业务模板
定义业务逻辑边界，无事务性保障，但蕴含了异样解决 / 日志埋点等通用能力。
通用查问模板
定义查问逻辑边界，与通用业务模板相似，但次要面向单项 / 批量 / 分页等查问场景。
音讯
对消息中间件的简略封装，适配业务利用规约，升高配置老本。
调度
对调度中间件的简略封装，适配业务利用规约，升高配置老本。
服务凋谢
api 组件标准对外服务能力，通过注解辨认服务定义和服务实现，主动生成接口文档，形容接口参数 / 返回 / 业务域 / 错误码等等。
其余——日志 / 异样解决 / 申请参数 / 返回类型
这里不做开展。
以上是所有业务利用都会遇到的技术细节，用组件屏蔽细节的思路也没有简单之处，咱们想要表白的重点是：尽可能积淀和复用技术组件，尽可能应用别人的成绩，不要反复搭建，把重心放到业务上！
2 畛域——专一业务建模
再次强调，对业务技术来说，业务建模是外围，业务建模是外围，业务建模是外围！本文的初衷和计划都是为了让开发解放出来，直面外围业务的设计和思考。本大节仅给出畛域产出的根本要求，后续在【案例剖析】再做详述。
畛域实体
建模的外围是形象出畛域实体及其关联关系，不同的业务场景和设计思路，会有很大差别，最终会体现为一到多个畛域模型。须要明确在不同业务流程下，各交易模型内须要蕴含的畛域模型（比拟形象，后续在【案例剖析】再做详述）。
畛域仓储
定义数据模型，及其与畛域模型的对应关系（各种 converter）。基于上文提到的仓储组件，配置数据库表和连贯，实现锁定查问 / 插入 / 更新 / 一般查问等业务行为。
畛域服务
基于业务行为，形象出原子化的畛域服务能力。该服务无需关注数据仓储，无需关注业务流程，仅形象出畛域实体的原生能力。以上文中提到的应收账款模型为例，至多须要蕴含：
应收账款的创立
应收账款的拆分 / 流转
应收账款的销毁
等等根本行为。
交易实体
用于承载交易流程的业务实体，上文中交易模型的业务实例，外部关联一到多个畛域实体。
交易仓储
用于管控交易实体以及外部各畛域实体的仓储行为。
3 服务编排引擎 —— 积木 + 粘合
凡是波及简单业务流程的利用，都须要引入流程引擎来编排状态机的流转。业界有很多成熟的流程引擎框架，也有很多足够可用的简化版本。但如前文所说，这类通用引擎的长处也是其最大的弱点：过强的灵活性无奈对设计格调造成束缚，大量业务细节会扩散在不同状态节点间，不直观也难保护。从本身需要登程，咱们设计了面向业务的服务编排引擎，以遵循业务设计规约的形式束缚技术，以直观的模式形容业务流程。与传统流程引擎相比，其业务敌对性次要体现在：
束缚业务模型：需明确指定业务交易模型 / 状态及仓储定义，遵循业务设计规范
托管仓储行为：只需配置业务模型及仓储实现，无需再关注数据长久化的机会和细节
编排畛域服务：通过转接层，将畛域服务凋谢到引擎中自在编排。畛域的原子能力是引擎编排的最小执行单位
灵便增减状态：流程中的状态迁转和业务行为均可被灵便插拔
反对“积木”扩大：将可复用的畛域服务组合打包，造成固定模式，作为“积木”在其余流程中重复使用
总的来说，服务编排引擎基于通用组件屏蔽技术细节，重点专一于业务行为的编排和复用，对“积木”进行“粘合”，以编排出合乎业务需要的业务流程。
四 总结
本文从业务技术团队的事实痛点登程，尝试以业务架构设计规约（实践规范）联合业务架构规范计划（工程束缚）的思路对立团队的技术格调，将技术同学从细节中释放出来，专一于技术能力的积攒和对业务价值的思考。心愿传播的想法有：
用规范束缚技术细节：升高业务设计的灵活性，也是为了缩小老本
用技术工具而非文档推广规范：继续积淀的组件，胜过没有约束力的文档
继续重构而非造新轮子：正视本人和别人已经的产出，继续改良能带来成长
器重业务建模：好好思考业务和行业吧，用 DDD 武装本人，晋升建模思维和能力
原文链接
本文为阿里云原创内容，未经容许不得转载。
