忙了一段时间，主要是梳理了一下我们B端资产和供应链的业务架构，经过这段时间的思考和沉淀，把如何做业务架构简单总结一下，重点讲一下自己的思路。

架构的本质是什么？

架构这个词有点烂大街，每个人对架构都有自己的一套理论，市面上也有各种各样的技术资料，从clean code，到设计模式，到一些介绍软件架构的书籍；但是，我还是花了很久的时间去琢磨一个简单的事：

  • 架构的本质是什么？

刚开始的时候，这个问题摸不着头脑，于是只能通过下面的问题去逼近：

  • 怎么才能算是一个好的架构？

这个问题貌似很容易找到一些答案：

  • 低耦合，高内聚
  • 模块化
  • 扩展性好
  • 模型清晰
  • 。。。

很多标准去衡量一个架构的好坏，但是，对我而言，总是感觉没有触及问题的核心：架构的本质是什么？所有这些感觉都是从架构的表象来描述架构，而不是从架构的内部。

从一次失败的设计说起

先说一次失败的设计，当时参与讨论的时候很草率了给了一个方案：

我们要设计一个网关系统，将我们上层业务的一些资产的变更同步给公司的一个财务系统，网关负责同步的细节，比如，重试和日志等工作，业务自己组合好需要同步的数据，直接交给网关就好。

即使再回过头来看，这个方案也没有明显的确定：职责清晰，分层清晰，容易扩展。但当这个方案落地的时候，一个熟悉业务的同学立马反对，说这样业务需要做很多重复的工作，他建议把架构改成下面的样子：

这个方案的优点在于：简化了业务接入的成本，业务只需要发送ID类似的消息就可以，然后由平台进行数据的组合后再同步给第三方系统。

对比这两个方案，想了好久：

  1. 凭什么说第二个方案好？当然第二个方案更加内聚，通过消息的方案也更加灵活，最吸引人的地方在于节省了业务接入的成本；但更加“本质”的“好”是什么？
  2. 如何在设计出第一个方案的时候，通过一系列的“标准”，能够推演出第二个方案呢？

想了好久，第二个方案的本质是：提高了业务接入的效率，效率就是生产力，所以说，第二个方案的本质是：能最大限度的提高生产力。

换个角度看架构

顺着生产力的思路进一步想了下，对比与人类社会（不严谨，仅供参考）：

软件架构 人类社会
起步 单一应用 一个人需要掌握生存的全部技能
发展 模块化，服务化 分工

终于，给服务化好找了一个“内在”的解释，然后，继续扩展完善一下：

社会 软件架构 思考
需求 顶层设计 架构的顶层设计，就要去思考我们的业务能够满足什么需求，业务存在的意义是什么，这一步是需求驱动的
竞争 规划 满足需求之后，要想在社会中生存下去，就要面临竞争的问题，这也是市场的规律，所以，我们去做架构设计，要想清楚规划
分工 服务好，模块化，领域化 分工促进了社会的发展，因为分工能提升效率，所以，单一的应用效率会受限制，必然出现：服务化，模块化，以及领域化
合作与共赢 中台，平台 合作是现在社会发展的基本模式，我们的软件架构也要从“合作”的角度去思考，沉淀出平台和中台，并且确认好它们的边界：让合作的各方实现共赢。

所以，对于我而言：

  • 架构的本质，就是为了实现生产力的提升。

整体的架构思路也应该顺着这条主线去思考：

  1. 明确需求，从顶层去设计架构要解决的问题
  2. 观察分工，当前的业务或者团队，是否面临分工的问题，是否到了必须分工的地步，如果是，那么架构就要分层，服务化
  3. 思考合作：满足了我们自己的业务，是不是我们要跟其他业务合作共赢，其他业务的诉求和利益是什么？这决定了我们架构的边界，边界清楚之后，就可以沉淀出我们的平台或者中台。
  4. 竞争和发展：需求是我们业务存在的理由，但是不是生存下去的保障，所以，要从架构层面去思考竞争的格局，做长远的规划才能长久的生存发展下去

自己的架构体系

一直觉得每个人都有自己的架构的体系和思路，结合对架构的理解和实施的时候遇到的一些问题，我总结了自己的架构的思路：

整体的认知包括三个部分：

  1. 生产力的提升：架构的本质，任何的架构都要问自己，这个架构提升了我们的生产力和效率吗？是否从需求，竞争，合作方面进行了充分的思考和调研；架构的边界是否能够匹配合作的形式？是否能够让参与的各方实现共赢？

  2. 时局：时局由两层含义：时间和局势。时间包括实施的时间长短，当前业务的紧急程度；局势包括了团队的资源情况，业务的侧重点等；任何一个架构都是理想和当下的平衡。

  3. 实施：就像盖楼，有了图纸，有了资源，下一步就是实施，实施也要考虑清楚，使用小推车还是起重机？是用砖还是瓦？这些就需要在落地的时候想清楚。