关于业务架构的一点思考

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，对于我而言：

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

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

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

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

生产力的提升：架构的本质，任何的架构都要问自己，这个架构提升了我们的生产力和效率吗？是否从需求，竞争，合作方面进行了充分的思考和调研；架构的边界是否能够匹配合作的形式？是否能够让参与的各方实现共赢？
时局：时局由两层含义：时间和局势。时间包括实施的时间长短，当前业务的紧急程度；局势包括了团队的资源情况，业务的侧重点等；任何一个架构都是理想和当下的平衡。
实施：就像盖楼，有了图纸，有了资源，下一步就是实施，实施也要考虑清楚，使用小推车还是起重机？是用砖还是瓦？这些就需要在落地的时候想清楚。