以往开发、测试、产品设计、项目管理的工作经历，对于架构工作来说都是财富。而那些架构理论、模式及案例，就好比一颗颗珍珠，每颗都光彩夺目，但在 具体实践过程中，似乎理论和实践无法很好地衔接，就像缺少一根串起珍珠的线。本文梳理了平安科技首席应用架构师蔡学镛的架构设计方法论，这套方法论整合了 多种架构设计理论，能够让架构设计工作变得更加流畅和高效。

　　在职业规划中，程序“猿”会有多个进化方向：项目经理、产品经理、技术专家、架构师、售前经理等。不同的选择有不同的憧憬，但也预示着不同的挑战。站在人生的十字路口踯躅不前时，你的脑海中是否曾掠过这样一个念头——没的选择有时也是一种幸福。

　　这是我曾经历过的一种状态。缺什么补什么，网络上职业规划相关的信息就会引起我的注意。偶然的机会，看到了蔡学镛老师这方面的坦诚分享。一路走来， 有坚持，也有放弃，而这些取舍的背后就是兴趣，强化优势，然后围绕着兴趣去突破自己，放弃弥补非致命缺陷。在痛苦面前，人的本能反应就是退缩，怀疑之前的 选择是否正确，一旦开始怀疑就会让你停滞不前。如果是外物促使你选择了某条路线，那你极有可能就放弃了。而如果这条路线是你的兴趣所在，那情况就会完全不 同，它会让你乐在其中，在遭受挫折之后很快满血，热情投入，不断突破自己。

　　古人云：知之者不如好之者，好知者不如乐之者。爱因斯坦曾说：兴趣，是最好的老师。排除外部干扰、倾听内心，我选择架构师作为我下一个阶段的进化方向。

“高大上”的架构师之路

　　当金融遇见互联网会发生什么？移动支付业务保持高位增长，10年内60%的信用卡将会被移动支付取代，15年内90%中小金融机构的前台将被取代。 移动化、智能化、云计算和大数据将成为主流，这就是颠覆式的互联网金融。变革的时代，孕育着无限机遇，但同时也隐藏着巨大的挑战。相比于传统的企业级系 统，互联网系统有着不同的特点，如表1所示。

 

 

　　可见，架构工作对素质和技能的要求更“高”了，以往更多是做精做专，现在是要在精专基础上寻求广博；要求具备更“大”的眼界，不仅只关注一个阶段的 细节，而要关注整个产品生命周期；为输出高质量的架构设计，需要面对的“上”游客户更多了，还涉及各类干系人及制度规则、商业环境、政策法规等。高、大、 上，架构师之路任重而道远！

　　这些年，我也读了不少架构书籍，参加了一些专业交流和培训。这当中有介绍架构理论的，有介绍架构模式的，有分享架构案例的，也有培训分视图做架构 的。业界也出现很多新的理论和模式，其中有些非常经典，例如DDD、REST、SEDA等。而这些理论、模式及案例，就好比一颗颗珍珠，每颗都光彩夺目， 但在实践过程中，我觉得理论和实践无法很好的衔接，就像缺少一根串起珍珠的线。

　　俗话说：读万卷书不如行万里路，行万里路不如阅人无数，阅人无数不如名师指路，名师指路不如自己开悟。阅读经典、项目实践、同行交流，短期内都不能 帮自己突破瓶颈，如果能够得到名师的指点，或许就可以打通任督二脉。与往次不同的是，这次蔡老师是作为平安集团互联网架构师、平安科技首席应用架构师的身 份做架构设计方法论培训。据个人了解，业界从规格到实现的方法和经验分享非常多，但衔接需求和规格的可操作方法论比较少。而这套方法论既整合了多种理论技 术，又具备很强的可操作性。

蔡氏架构设计方法

　　针对问题域的特点，这套方法论采用与之相对应的多维度、立体化、分层次、动态演进的策略，通过空间（X、Y、Z）三个维度及时间（T）维度将问题域 解构成可以轻松应对的小方块，分而治之。同时，空间（X、Y、Z）三个维度联动，专门为单个维度解决不了的问题提供解决方案。时间（T）维度将问题分解到 一个时间范围内，分步骤按节奏逐一解决，如图1所示。接下来，让我们进入这个四维的架构时空一探究竟吧！

 

 

【四维座标系统】

1. 前后端维度（X1 … X7）

 

 

　　前后端维度被分解为交互、业务、领域、资源四大层，其中业务可以细分为应用X2、框架X3，领域可以细分为服务X4、核心X5，资源也可以细分为代 理X6、数据X7，共七个层次，如图2所示。服务X4可以实现API，如果公开，就是开放接口，调用服务层的接口，通常需要授权。代理X6可以实现 SPI，隔离耦合，避免核心X5依赖特定的外部系统或数据库。每个层次做到高内聚，层与层之间做到低耦合，详见表2中的X轴七层架构模型及定位所示。

 

 

　　在系统实现过程中，可以综合考虑现状，X2应用和X3框架可以不分拆，X4服务和X5核心可以不分拆，待后续时机成熟可以再重构分层，这样变更范围仅在内部。

2. 业务维度（Y1 … Yn）

　　从业务维度进行划分，按照业务类型对系统进行分类。业务系统的划分更多依赖业务领域的知识。这个维度的设计方法，本文暂不深入介绍。

　　当Y轴的一个业务系统需要调用Y轴的另外一个业务系统时，兼顾效率和耦合，这套架构设计方法论给出了具体的架构原则，如图3所示。

 

 

（1）当被调用的是公共系统时，那么调用将被视为内部调用，即服务可以直接调用服务。考虑到公共系统比较稳定，不会经常改变，直接调用可以减少调用环节，保障效率。

（2）当被调用的是非公共系统时，那么调用将会被视为外部调用，即通过代理层去调用被调用系统的对外服务接口。这相当于把两个系统后台进行了串联，降低了系统之间的耦合，后续被调用系统发生变更，对调用系统的影响也可以借由其代理层进行了隔离。

 

 

3. 系统维度（Z1 … Zn）

　　该维度主要关注软件、容器、运行时、操作系统、虚拟机、硬件等这些与业务无关系统的架构。Z轴的系统可以分别用于前端优化、应用优化、平台优化、资源优化等层面，如图4所示。

4. 时间维度（T1 … Tn）

　　对于一个新产品来说，架构不是一次成型的，从初始到成熟要经过一个不断演进的过程。对于一个已有产品来说，架构的优化也是要结合实际情况分步骤实施。

　　除了技术上的考虑之外，我们还需要考虑市场及投资等方面的情况。通常在研发初期，产品本身的定位还不太清晰，需要快速地迭代投放市场获取先发优势以 及验证想法，不断地明确产品的定位。这个阶段产品需求变动非常频繁，许多架构的驱动因素尚未明确，如果过于关注架构，那产品推向市场就会遥遥无期。随着产 品定位的逐步清晰，架构的驱动因素及约束条件都逐渐浮出水面，这时架构设计的重要性就显现出来了。另外，我们还需要根据投资预算来调整架构设计。如果投入 比较充裕，那我们就可以投入更多的人力来提前将架构驱动因素研究清楚，甚至可以针对不确定的约束提供多套备选方案。

【X轴设计——架构设计流程】

　　如图5的架构设计流程图所示。

　　第一步，结合现实情况，将系统划分成多个层次。

　　第二步，确定层与层之间的关系，梳理出层与层之间的交互接口。

　　第三步，将功能相近的接口划归到一个模块，确保模块高内聚，对外低耦合。

　　第四步，以上面为基础，进一步明晰接口的参数列表。

 

 

　　仅仅四个步骤就完成了架构设计吗？这会不会太简单空洞了呢？各位看官，不要着急，请听蔡老师慢慢道来，每个步骤都有极具可操作性的方法及工具。

1. 层次的切分方法

　　面对一个庞然大物，你该如何下手呢？不用担心，这已给你准备了庖丁解牛的方法，轻轻松松把一个复杂的大系统变得可以掌控了。

　　第一刀：按照这套方法论来进行架构设计，最理想的情况是将X轴切分成七层。而第一刀应该先切在业务和领域之间，即通过API把两边解耦。交互和业务跟用户关联度高，经常随需求变化而改动，而领域和资源相对比较稳定。

　　第二刀：考虑到要完成某些业务功能，系统可能需要调用外部系统来协同完成，为了保证领域层相对稳定，我们需要隔离外部系统或数据持久层变化带来的影响，第二刀应该切在领域和资源之间。

　　第三刀：考虑到同样的一个业务可能会有多套界面，例如有Web版、桌面版、移动版等，为了提高重用，隔离变更，接下来要把交互和业务切开。

　　通过上面这“温柔的三刀”，我们就可以把一个大块头切分成七个层次。

2. 接口的设计方法

　　在确定分层之后，我们可以把每个业务需求的交互时序图画出来，而分层就是交互时序图的主角，如图6所示，这时我们就可以清晰地找出层与层之间的交互接口，以及可以初步确定每个接口的参数列表。

 

 

　　考虑到API、领域模型接口、SPI是最为关键的接口，那良好的设计就显得更为重要。如何能够设计出良好的接口？如图7所示。

 

 

（1）找出领域对象：通过多轮领域访谈，与业务专家一起分析出领域对象。另外，也可以通过研究外部接口及数据字典来明晰领域对象，反过来也可以丰富外部接口和数据字典。

（2）设计领域模型、资源模型、数据模型：在挖掘领域对象的过程中，我们就可以开始设计领域模型了，确定领域对象之间的关联关系。当关联关系逐步清 晰之后，我们还可以根据关联关系的密集程度对领域对象的组织方式做一些调整，找出核心的领域对象集合，其他领域对象可以归类到围绕核心领域对象集合的卫星 集合里面。通过多轮调整，可以得到一个能够映射业务、关系简化的领域模型。然后兵分两路启动资源模型和数据模型的设计工作。上述三个模型之间的关系及区 别，请参见下文。

（3）设计领域模型接口、API、SPI、数据库：在设计领域模型接口时，要尽量做到不多不少，这些接口都是对外提供服务所必需的，也是全面的，并 且粒度要细。在设计API时，要考虑内外客户的需求和特点，做到方便易用，可以参考RESTful API设计相关的资料。在设计SPI时，要尽量隔离资源层对领域层的影响。

在完成上述工作后，我们就可以进入实施阶段，开始启动代理层、核心层和服务层的代码设计工作。另外，如果是对线上已有系统进行升级，那还要开始制订数据的迁移计划。

3. 三个模型之间的关系及区别

　　领域模型，映射特定业务领域当中核心领域对象及其关联关系，这些对象及关系的存在都是完成业务规则所必需的，甚至是法律法规等明文要求的，不会轻易变动。

　　资源模型，基于领域模型，从为内外客户提供服务的角度分析定义出来的，包含了资源对象及其关联关系。根据内外客户的特点及需求，我们可以调整资源模型中的内容。

　　数据模型，基于领域模型，从存储（持久化或缓存）信息的角度分析定义出来的，包含数据对象及其关联关系。根据存储载体的特点及需求，我们可以调整数据模型中的内容。

4. 接口类型的分类方法

　　如何确定图形用户接口（GUI）和应用编程接口（API）的分工呢？如图8所示，在收集业务需求的过程中，我们可以标识出发起这个需求的角色是人还是程序。如果发起需求的是人，那就需要通过GUI来满足；而如果发起需求的是程序，那就要通过API来满足。

 

 

5. 模块的设计方法

　　架构设计流程第三步，按照功能相近的原则将接口划归到不同的模块当中。划分模块就会涉及业务拆分。如图9所示，跟分层第一刀位置一样，我们选择业务 层和领域层的交界处来做业务拆分。业务拆分需要跟业务专家一起来完成，通过这个过程可以确定出Y轴包含哪些业务系统，而这些业务系统的公用模块或系统将会 被划分到业务层X2、领域层X4当中。

 

 

　　在做完第一轮业务拆分之后，就可以进入设计阶段，确定业务的交互流程，进一步明确业务层X2、领域层X4。然后并行启动交互设计和建模，其中交互设 计是为了确定交互层X1和业务层X2，而建模是为了明确领域层X4、X5以及资源层X6。设计和业务拆分可以迭代多次，直至可以进入下个阶段——模块设计 及数据存储设计。

　　根据业务设计的结果，我们可以进行模块设计，明确X1到X6等层的模块组成。而建模的结果可以用于数据存储设计，明确X1、X3、X6、X7这些层 次的模块划分。模块设计和数据存储设计可以互相推动。当上述设计都完成之后，就可以进入网络部署规划，最后就可以做人员机器规划，进入实施阶段。随着实施 深入，发现问题后及时重新迭代整个过程。

在实战中践行理论

　　诚如蔡老师所说：干货甚干，请配合开水服用！那我想这开水就是实践吧。打铁趁热，我把正参与的两个项目作为实践这套方法论的战场。

　　这两个项目各有特点，在实践过程中就会有不同的挑战。其中，壹企业，是平安首个基于SaaS云技术打造的企业管理平台，满足中小企业人事、财务、客 户关系等管理需求，是一个全新的项目。而信用卡坐席系统二代是一个升级项目，一代系统已服役了很多年，累积了许多可以继承的子系统和模块。

　　壹企业的系统架构如图10所示，X轴切了两刀半，这样资源、领域这两层就形成了。资源层内部再细分为代理和数据，其中代理负责数据访问及调用外部系 统服务，并以SPI方式向领域层提供服务。领域层内部再细分为服务和核心，其中核心就是领域模型的实现，而服务就是资源模型的实现，以API方式对外提 供，并计划加入到开放平台（Open API）当中，服务于更多合作伙伴：第三方应用提供商。

 

 

　　信用卡坐席二代，这是我们非常熟悉的一个业务领域，市场价值也是可以预期的。基于上述前提，信用卡坐席二代在X轴上切分为交互、业务、领域、资源四 大层。其中，交互层就是以界面为主；业务层暂不分应用和框架，均统一在应用里面；领域层分为服务和核心，其中服务将加入开放平台（Open API），核心就由信用卡开放平台承担；资源层分为代理和数据，负责数据持久化，以及与信用卡业务相关的外围系统进行交互。

　　懂得很多道理，不一定能过好这一生。而懂得这套方法论，那架构设计就可以做得更好！分享的意义更多在于梳理自己认知，加深对这套方法论的理解。鉴于个人水平有限，文中一定存在些许偏颇之处，欢迎大家交流指正，一起玩转这套蔡氏架构设计方法论。

　　文中许多想法来自严云涛、孙国勇、江琳、曾荀、王刚、许扬、颜诗超、杨果林等小伙伴们的分享与讨论，在此向大家表示感谢！

　　另外需要说明的是，文中部分插图源自蔡学镛老师的培训教材《软件架构入门》及书籍《编程ING》。

　　作者：徐胜勇