什么是体系化？为什么要体系化架构

写在前面

为什么要聊体系化？最重要的一个原因是“卷”。

假期和朋友聊天，说我们在搞“产品体系化解决方案”，究竟怎么搞呢？不知道。

我说“你们不是才搞完产品领域化吗？怎么又搞新的？产品领域化有什么收益吗？”

他说老板给到他的就是一个命题作文，“把咱们产品体系下的技术、系统、概念以体系化方式呈现，也就是“产品体系化””。

之前的文章中我们提到过目标和问题的重要性，做任何事都要师出有名，所有的目标围绕于解决什么问题？或一个目标？体系化的背后究竟有什么痛点、难点？老板也没想明白，只是甩给了他这个命题作文。

看这不是“内卷”了吗？

大厂内卷的一个重要的参照物就是“开始输出概念了”，之前和阿里老员工聊，说：“你们阿里现在输出的概念比解决的问题多啊”，他说：“不输出概念怎么晋升？”。第一年ppt内容是“xxx数字化”第二年变成了“xxx数智化”，方案差不多，概念先占一个。

卷也有卷的道理，如果你老板给你一个这样没有明确目标的命题作文你会怎么搞？不知道。

但是尝试聊聊，说不定哪天用到了。

体系化思维

为什么需要体系化思维？

日常工作中，我们面对的问题是散乱的、非结构化的，问题不够聚集，导致我们的解决问题的效率不高，产出也不够清晰。

所以我们需要在工作中找到主线，将面对的问题有条理的梳理出来就非常重要。

一般怎么梳理呢？

可以针对复杂问题，列出关键要素和解决方法，将散乱无序的问题变得有逻辑可循。

完整的体系化思维包括：明确目标、拆解问题、细化方案、执行落地、闭环总结、项目迭代等几个核心环节。

通过以上体系化思维，可以帮助我们基于现状、问题、目标产出一套高效优化工作效率的框架思维。

明确的目标是做好体系化的第一步，目标是全局动作的驱动力，展开的一些动作都是服务于这个目标。

拆解问题可以帮助我们直面问题，直面解决过程。不仅着眼于目标，更多是带入解决问题的情境中去思考解决方案。

细化方案是罗列出针对于每个问题的解决方案，方案的细化要保证具备极强的操作性和可衡量性，以便在方案落地过程中和后期评估方案的效果。

执行落地是协调资源落地的过程，执行过程中沟通必不可少，良好的沟通可以更有力的推动工作开展，保持团队内信息高度一致，明确进度和人员定位，事半功倍。

闭环总结可以从三方面展开：数据效果总结、方案流程总结、沟通执行总结。前两个是针对于工作过程的总结，重视处理专业问题的能力和方法。后者针对的是团队成员“人”的总结，重视个人发展和团队培养软实力。

项目迭代是让项目进入新阶段、新高度的起点，在一个新的环境下重新回到第一个阶段，明确新的目标，开始新一轮的增长。

所以体系化思维是一种整合全局业务流的思维，通过适当的分解工作内容，梳理工作环节之间的内在联系，搭建完善的体系化框架，来保障工作持续高效运行，创造价值。

怎么将体系化和技术结合起来呢？

体系化讲的是流程、分解、组织、搭建框架这些东西，那我们做技术过程中有哪些是需要分解、再组织、以框架方式整合的呢？

尽管我们在工程实现之前分析时，有各种框架（Spring、MVC），采用了各种模式、模型（DDD、SOA、微服务）。但落地过程中避免不了业务逻辑分散在各个系统当中，出现各种跨module、跨服务的隐式耦合。这种分散势必造成应用架构的割裂，如果没有持续的重构与调整，最终会变得复杂臃肿。

究竟什么原因导致这种情况的呢？

尽管我们有各种工程框架、研发规范，但这种约束过于灵活，也更过于“技术化”。缺少以业务视角进行设计规范，也就导致了同样类似的方案最后实现上过于差异。

早期项目开始之时，由于需求背景较为清晰，业务复杂度不高，系统、模块在设计与实现上有比较明晰的边界，随着业务的发展，系统冗杂了过多新业务代码、适配业务代码，而且每个阶段功能实现人的设计思维不同，同时系统架构缺少约束力，导致架构实现的复杂度变高，开始腐化。

用曾经的架构来设计当前的业务场景，但可能引入大量额外的成本，丧失了原本设计的优势，后期需要做大量的减法。

喜欢造轮子而不是持续对轮子重构，研发同学有洁癖“玄学”，编码风格各领风骚，往往对前人设计“重构”更来得快些。

靠文档传承而非工具复用，很多新人说老人留下的文档太少了，建议提供标准、准确的需求文档及数据库设计详细er图，还有些团队为了搞“降本增效”，强推API DOC，然而并没有卵用，归根接地的问题在于，研发工程师没有“义务”去持续优化这个DOC，国外软件公司，如微软其实是有专门的api文档团队的，国内公司基本没有，所以在文档交接这块不要期望研发可以多做一步。

为解决以上问题，就会想，在业务架构实现过程中，除了具体技术实现之外，有没有一些业务维度的普世价值观在业务架构设计领域或某个领域内，建立一套面向业务研发同学的“设计规约”呢？

几个关键词：

标准：统一业务设计框架，用标准化架构简化技术细节

沉淀：从业务场景中持续沉淀积木、轮子、组件

重构：持续重构积木，减少重复建设

集成：基于业务服务编排引擎快速集成

标准

标准的本质在于减少细节，理想状态下，业务研发只需要关注于领域建模，但真实落地过程中不得不考虑很多通用技术的实现细节，比如供应链金融场景下应收账款流程：

1. 领域建模：应收账款领域模型及其行为的设计
   

2. 流程编排：流程模型的设计及发行流程的状态机设计

3. 数据转换：领域模型 -> 数据模型及流程模型-> 数据模型的双向转换

4. 并发控制：业务锁机制设计

5. 业务幂等：流程中各业务环节的幂等控制

6. 异常处理：异常捕捉，错误码约定

7. 监控报警：摘要日志，异常日志，边界日志

8. 其他

看下来，除了“领域建模”之外都是和基本的业务无关的，但同时也是不可或缺的。所以需要一套标准化的框架方案，以统一的规范解决掉业务无关的大量细节，让业务研发同学专注“领域建模”。

沉淀

沉淀的本质在于能力复用，能力复用不局限于形式和粒度，以降低技术成本为核心，提高业务扩展性，就可以看做是满足了沉淀的目标。所有沉淀下来的东西都可以作为组件为后期复用。

沉淀的组件包括：技术类、业务类、平台类。

技术类：

1. 工程规范：约束编码规范和边界接口定义风格，日志打印、异常处理、仓储行为、状态机等。

2. 读写分离：屏蔽交易类需求与查询类需求对接数据库模型的差异，降低设计复杂度、提高查询性能和灵活性。

业务类：

1. 网银核身：提高网银核身签名在不同业务流程中的扩展性
   

2. 合约上链：提高智能合约对接在不同业务流程中的扩展性

平台类：

1. 配置中心：灵活定义和管理业务流程需要的各类配置项
   

2. 产品中心：平台功能打包和隔离，实现业务流程全局视图

重构

重构的本质在于持续优化，我们基于历史的业务理解沉淀下业务需求，但很难直接适用于新的业务场景下。这也是后来人很难复用千人设计出来轮子的原因。这也是很多团队说在做沉淀，但可以在横向复用或持续输出的可复用的轮子少之又少，看起来没有完美的解法，但我们对于一个好的可复用的轮子是有标准的。

集成

集成的本质在于灵活搭建，为保障标准化的落地，有了可复用的轮子之外，还需要有灵活的粘合剂，这样才能真正实现灵活、快速的搭建与调整。

在很多业务场景下，业务需求主要体现为支持各种各样的业务流程，为简化积木搭建，灵活复用底层能力，可以设计面向业务的服务编排引擎：

1. 标准化：遵循设计规约，将业务无关的通用技术细节屏蔽

2. 插件化：对轮子友好，可持续沉淀和复用新能力

3. 业务化：面向业务，有业务描述能力的流程编排

4. 配置化：通过配置即可完成流程编排，最好可以做到可视化编排

产品

技术是服务于业务的，为实现全流程承接，我们需要业务大图。以轮子+粘合剂可以满足技术落地的低成本的高扩展性，在结合业务大图来描绘业务线的全域能力和功能流程。

有了这么多概念，是不是还不知道怎么做？

那我们看下善造概念的阿里同学是怎么做的。

业务架构标准方案

整体解决方案我们称为：业务架构标准方案。

前面说了只靠文档形成的共识，对技术是没有约束力的。于是我们不期望建立一整套全局业务大图下的API DOC，而是通过组件化工具的方式约束业务应用，形成团队共识，生成一套标准化的业务架构设计方案。

标准的业务应用架构如下：

组件：规范技术实现细节

通过组件化约定，约束通用技术细节行为，如：

交易模型：描述了业务流程的核心交易模型，用于管控状态推进，维持与业务模型的关联。

仓储模型：数据持久层的通用行为收敛，包括锁定查询、数据的插入、更新、通用查询等。

事务模板：定义事务边界，确保模板域内业务逻辑的事务一致性，支持幂等。

通用业务模板：定义业务逻辑的边界，无事务性保障，包含基本的异常处理、日志埋点等通用功能。

通用查询模板：定义查询逻辑边界，与通用业务模板类似，但主要面向单向、批量、分页等查询场景。

消息：对消息中间件的简单封装，适配业务应用规约，降低配置成本。

调度：对调度中间件的简单封装，适配业务应用规约，降低配置成本。

服务开放：api组件规范对域外服务能力的衔接，通过注解识别服务定义和服务实现，自动生成接口文档，通过描述接口参数、返回、业务域、错误码等。

其他还包括：日志、异常处理、请求参数、返回类型等技术细节。

上面是所有业务应用都会遇到的技术细节，用组件屏蔽细节的思路将技术复杂度封装起来，我们逻辑重点在于：尽可能沉淀和复用技术组件，不重复搭建，将研发重新放到业务上。

领域：专注业务建模

技术是服务于业务的，相信每一个从事业务架构研发同学都深知这一点。而业务以建模为核心，所以在整个研发流程中，我们最应该持续投入的就是业务研发阶段，直面核心业务设计与思考，应该让研发同学从其他研发环节中释放出来。

那如何基于领域建模实现领域产出呢？

领域实体：建模的核心是抽象出领域实体和其关联关系，不同业务场景下设计思路不同，最终体现为一到多个领域模型。

领域仓储：定于数据模型及其领域模型之间的对应关系，通过上面提到的仓储组件，配置数据库表和连接，实现锁定查询、CRUD等通用业务行为。

领域服务：基于业务行为，抽象出原子化领域服务能力，领域服务无需关注数据仓储及业务流程，仅抽象出领域实体的原子能力即可。

交易实体：用于承载交易流程的业务实体，内部关联一到多个领域实体。

交易仓储：用于管控交易实体及内部领域实体的仓储行为。

服务编排引擎：组件+粘合剂

但凡涉及到复杂业务流程的应用，都需要引入流程引擎来编排状态机流转。业界很多成熟的流程框架，存在普遍的问题就是：过于灵活，难以约束设计，大量业务细节分散在不同状态节点之间，不直观也难以维护。

所以需要一套面向业务的服务编排引擎，以遵循业务设计规约的方式约束技术，以直观的形式描述业务流程：

1. 约束业务模型：需明确指定业务交易模型、状态、仓储定义，遵循业务设计规范

2. 托管仓储行为：只需要配置业务模型及仓储实现，无需关注数据持久化细节

3. 编排领域服务：通过转换层，将领域服务开放到引擎中自由编排。领域的原子能力是引擎编排的最小执行单位

4. 灵活增减状态：流程中状态迁转和业务行为均可灵活拔插

5. 支持轮子扩展：将可复用的领域服务组合打包，形成固定模式，作为轮子在其他流程中复用

总的来说，组件是屏蔽具体技术细节，服务编排引擎基于组件的编排，屏蔽更多的技术细节，复用价值也就更大，编排出更符合业务需求的业务流程。

总结

通过体系化技术框架，让技术团队从现实痛点触发，以业务架构设计规约（研发标准）结合业务架构标准（工程约束）来统一团队的技术风格，将研发同学从细节中释放出来，专注于技术能力的积累和业务价值的思考。

实现细节包括：

1.  标准约束技术细节：降低业务设计灵活性，降低成本
   

2. 用技术工具而不是API DOC推行标准：持续沉淀组件，胜过没有约束力的文档

3. 持续重构而不是重复造轮子：正式团队输出，持续带来价值

4. 重视业务建模：围绕于业务以DDD实现落地，提升建模思维和能力