我的架构师成长之路-三份架构作业

毕业以后，我喜欢上了敲代码，毅然放弃了自己的专业，加入了码农的行列，这一干就是7年。后来，公司提供了一个内部转岗的机会，我走上了系统设计和产品规划的道路，在该公司先后担任过SE和产品经理。最近10年我一直在数字产品领域，从事产品规划和和设计。由于企业需要，也兼过系统架构师和解决方案工程师，可以说一直游走就在产品和系统架构之间。从开发-》系统设计-》产品设计-》业务设计，我一直在探索和学习，有过挫折也有过收获。接下来，我分享一下我的一段成长经历：三次架构作业。我在一家企业加入了一个智慧银行项目，为某银行提供智慧门店解决方案。彼时的我是公司的产品总监兼架构师，负责产品和解决方案的规划和设计。

项目背景

银行数字化转型

随着互联网金融的发展，传统银行业不断面临压力和挑战，遍布城乡的网点网络带来存款、客户规模等优势，但同样面临离柜率攀升、网点资源浪费的挑战。很多人可能和我一年到头也去不了一次银行，我们在手机客户端上就可以办理各种业务，也就是所谓的“离柜”办理。在离柜率高达95%的深圳，银行业正在重新审视网点价值。

客户需求

从银行(本项目的客户)的视角，他们的需求不是关掉门店，而是通过资源的合理分配，服务不同需求的终端用户，提升坪效比。正如邮储银行深圳分行副行长陈旭辉所言：

“大量客户走线上渠道后，永远还有一批客户需要面对面的服务。如果失去了物理网点，银行就失去了阵地。只是，金融服务网点需要新理念进行场地规划，把空间合理分配给不同需求的客户。”

对银行而言，门店仍然是接触客户，尤其是接触高净值客户的触点，门店仍然有存在的价值。客户的需求是在保留门店的前提下，提质增效，挖掘门店的最大价值。具体包括以下三个举措：01探索线上与线下渠道如何融合发展

通过开发和建设智能厅堂、手机银行和微信银行等渠道，实践金融+生态圈建设和建设敏捷银行的目标。02探索新零售销售场景通过线下门店升级改造，打造智能化、轻型化门店。门店划分不同功能区，为客户提供业务办理、财富管理、休息洽谈等综合服务场景，提高坪效比。

03提供个性化产品和服务通过用户画像实现不同客户的个性化配置，使产品营销朝着个性化与定制化的方向发展。

用户画像

本项目的典型用户主要是两个群体：门店店长（支行行长）和区域管理者(分行行长）。

支行行长：支行行长需要的是一个店铺管家，可以通过主题的仪表盘，监控门店销售趋势、客户流量、转换率和目标完成率，提高门店店长数据经营的能力。区域管理者：区域管理者需要的是一个空中巡店助理，面向区域分公司、总部管理层，通过360度业绩监控对门店的销售数据和经营数据进行全面的监控和分析。

业务场景

银行门店的主要业务场景包括客户到店、客户引导和业务办理。业务流程和主要功能分解如下：

1. 用户到到店后通过人脸识别VIP用户，发送提醒(手环震动/手机短信)银行客服经理；
2. 用户到店后，提供机器人语音客服，用户可以通过语音聊天获取服务指引；
3. 银行可以发布金融产品信息、会员权益活动到互动触摸屏，用户可以点击浏览相关产品，并在线办理相关业务（或获取业务入口）；
4. 银行可以统计到店用户数，可以实时和查询历史用户数，银行员工不计入用户数。

需求分析、用户画像和业务场景分析是一个产品经理的基本功，在这方面我有多年的经验积累，交付物也很快和领导达成了共识，然而接下来在产品架构图上却出了问题。

第一份架构作业

在完成了需求分析以后，领导希望我通过三页ppt介绍我司产品，要求能覆盖产品功能、产品价值和解决方案架构。彼时的只会画两种图，一种是系统架构图，一种是组网图。系统架构图采用了标准的IAAS、PAAS和SAAS三层框架，如图：

组网图则是典型的边/端/云组网结构，如图：

这两部分没有太大问题，产品价值部分是我比较头疼的地方，第一个是如何描述产品价值，第二个是如何通过视图表达，尤其是表达产品价值和解决方案之间的关系。彼时的我没有学习过何业务架构的知识，不知道如何建立战略、需求、价值和利益相关者之间的关系。

在几番沟通之下，最后只能用文字表达产品的价值，没有进一步绘制成视图。领导对于这样的结果显然并不满意，第一次交付的架构作业并不成功。

第二次架构作业第一次”交作业“的失败让我开始思考面向业务层和战略层的建模。由于缺乏指导，我误打误撞先后学习了中台和DDD。

中台

中台是阿里在2015年提出的，自此后百度、腾讯、滴滴、华为、美团纷纷纷纷开始建设中台。中台解决的是多个业务线重复造轮子的问题和协同的问题。企业发展到一定规模为了便于管理就会拆分事业部，每个事业部独立运作，时间长了就容易重复造轮子。但由于分家分得不够彻底，存在职能重叠，可能前端分了，后端还在一起，系统之间存在相互依赖。

解决方法就是构建一个中间层，中间层是一种常用的软件分层设计技术。

中台是一个企业级复用平台，它通过中间层将前后端业务资源抽象为可复用的功能或能力，以API的形式支撑前端敏态业务如全渠道业务、互联网业务和上下游产业链业务。

我所在企业彼时并不存在多业务线，但多个应用之间存在通用的业务功能。如客户识别系统、客流统计系统、金融产品发布系统因为都包含了硬件。这些系统都存在设备管理模块，包括设备的注册和发现、远程控制等功能。如何复用这些功能也是我当时思考的问题之一。中台的相关概念正好补齐了我在这方面的知识空白点。然而中台缺乏理论基础，不管是业界还是公司内部对对中台并无共识，再加上彼时也出现了很多对中台质疑的声音，让我决定决定继续探索和学习新的架构设计方法。

DDD

DDD是软件大师Eric Evans于2003年提出的。DDD解决的是传统四层开发结构中贫血模型带来的问题。

在传统模型中，DAO层的数据对象是数据的载体，只有简单的get/set方法，没有业务逻辑，持久层的业务逻辑将会放到服务层中。这种模型中，DAO层的领域对象是不依赖于持久层(Model层)。这种模型看似减少了架构层的耦合性，但带来了其他新的问题，就是负责持久层的工程师（通常是后端工程师）和负责服务层的工程师(通常是前端工程师)缺乏充分的沟通和协同。随着时间的推移，业务需求不断增长与业务逻辑愈加复杂，基于贫血模型的数据架构往往不能够很好的匹配业务规则演进，导致业务对数据库表的访问盘综错杂，系统随时间推移急剧腐化，演变为一个复杂的大泥球。

DDD解决贫血模型的方法概括起来就是四个字“业务下沉”。DDD同样分为4层，包括用户接口层，应用侧，领域层和基础层。DDD和贫血模型最大的区别在于它将业务逻辑下沉到领域层，并封装到领域层的服务中。领域层直接面向持久数据层，包括了数据实体和领域服务。数据实体包括聚合根、实体和值对象，这些数据实体可以直接映射为数据持久层的表、字段和值。应用服务层只通过领域服务或数据实体来组织业务，自身不带任何实现逻辑。

DDD通过业务下沉，让业务和数据链接更为紧密(充血模型)，促进了后端工程师在和前台工程师(包括业务专家)的充分沟通和协同。DDD的另外一个好处就它通过领域建模，区分了业务域和限界上下文(业务子域)，而限界上下文是后续微服务划分的一个依据。

DDD不是完美的，它概念陈旧、术语含义模糊、无跨系统的建模指南。它虽然解决了业务和数据协同的问题，但它没有提供战略层的支持，无法回答价值在哪里这类问题。但DDD作为一个系统设计模型，它上通业务，下通数据和微服务，是目前笔者看到的最接地气的一个系统设计模型。这是笔者基于本项目用DDD方法实现的一个工作坊练习。

第二次架构作业

学习了中台和DDD，让我对多系统之间的功能复用，平台等概念有了基本的认识。在此基础上，我完善了原来的系统架构图，也就有了第二份架构作业。

企业架构

2020年我接触到了企业架构，这让我如获至宝。企业架构是一个学科，它就像企业的“城市总体规划蓝图”，在它的指导下，业务战略和IT战略可以更好地协同。

企业架构让我第一次有了战略视角，可以从上而下以一种更为全局的“上帝视角”来审视战略、客户、价值、产品、能力、服务和解决方案之间的关系。企业的战略视角包括：

· 首先需要考虑“Where ”的问题---确定企业的发展方向、目标客群和产品组合等。

· 紧接着要考虑“What”的问题---识别实现战略目标所须完成的关键任务及年度重要工作。

· 最后要解决“How”的问题---确保相关举措／项目能够顺利执行、交付落地。

· 在企业运行的整个过程中，需要通过合适的指标体系进行整体监控，以便及时感知企业战略执行落地情况，并根据企业需要适当地对战略进行调整和优化。

第三次架构作业企业架构提供一个可视化的建模工具Archimate，可以对战略层、业务层、技术层进行可视化建模。

第三份架构作业

战略视图

在战略层，我可以通过战略视图来描绘利益相关者的关注点和架构愿景，从而将业务能力、资源、举措关联到客户愿景、目标，解决了一直困扰我的产品和服务如何关联客户价值的问题。利益相关者关注点

• 数据战略：统一零售门店客户数据，提升零售客户服务水平，建立对零售客户做精准营销、行为预测等等一系列的能力，结合这些内容再对数据战略进行思考。
• 易用使用：操作简单，营销简单，管理简单，选择简单。
• 降低IT复杂度：摒弃垂直烟囱式系统，构建统一门户、统一服务、统一数据的信息平台。

架构愿景

• 数据化转型升级，提升决策能力，科技赋能企业；
• 获客模式创新，全渠道获客，精准营销，提高收入来源；
• 运营成本降低，减员增效，网点轻量级、标准化；

战略视图

业务流程图

在业务层，我通过业务流程图重新绘制了前文中提到的银行门店业务场景。

业务流程图

需求实现图

通过需求实现视图可以跨层构建一个包含业务功能、业务流程、系统部署、系统组件关系的一个全局视角。

需求实现图

职业规划

通过企业架构的学习，我也了解到除了传统的系统架构师外，还有企业架构师、业务架构师、数据架构师、应用架构师等不同领域的架构方向，也更明确了自己的职业规划，也就是从系统工程师往业务架构师和企业架构师方向发展。

总结

企业在演进，架构技术和架构方法在演进，架构师在也逐渐细分和专业化，因此架构师是一个需要不断学习的岗位，未来企业需要的是在专业领域精通又有全局视野的T字形能力架构师。

晚清学者王国维的把学习的境界分为三个层次。

第一层：‘昨夜西风凋碧树，独上高楼，望尽天涯路’；

第二层：‘衣带渐宽终不悔，为伊消得人憔悴’；

第三层：‘众里寻他千百度，回头蓦见，那人正在灯火阑珊处’。我的三次架构作业也正好对应了这三个境界，于我而言，对于业务架构和企业架构的学习也才刚刚开始而不是结束