本文分享阿里资深技术专家六铢的架构方，这套方中包含了详细的架构推导逻辑，希望能够帮助大家在工作中从各个粒度、各个层次来做好架构工作。较长，同学们可先收藏再看。
而这个过程是如何造成的呢?原因之一是每次迭代过程中都没有用正确的架构方法来进行迭代造成的，就像在歪楼上继续加盖楼层一样，最终还是会倒塌(不过这个原因并不是唯一的原因，其他原因留到后续文章中阐述)。
要解决这个问题，那就需要在每次迭代中，都需要用正确的姿势对不对?要用对姿势其中有一个重要的原因是架构。就像一幢大楼，架构设计得越有问题，这幢大楼被重造的可能性就越大。
这里正确的姿势到底是什么姿势?接下来本文会阐述一整套架构方，该方中包含了详细的架构推导逻辑，帮助我们在工作中在各个粒度，各个层次做好架构工作。
我们后续的文章中将会着重阐述如何通过自底向上以及自顶向下的两种架构思考方式来解决这些问题，但是在那之前，我们还是先来聊聊什么叫“架构”。
大概是在 11 年前左右，在土豆网做广告平台，同时也做视频 CDN 的相关事情，当时做一个服务，基础架构是 lighttpd + squid + tomcat，将静态资源分离到 httpd，get 请求使用 squid 缓存，智能路由使用 HTTP post 请求，并让 tomcat 提供服务，当时就觉得这就是架构。再后来，做了视频 CDN 相关的基础建设的工作，就觉得这就是做架构，关键那个时候也没有人告诉我们什么架构，自己不知道自己不知道。
再后来慢慢成长，又去做了几年中间件(包括高性能 RPC 和 JSR-170)，然后就觉得这也是做架构。当时也没有前辈跟我讲什么是架构，那个时候的我对架构是没有体系化认知的，都是凭着感觉做的，是不知道自己不知道。
再后来，来到了阿里做应用研发和架构了，发现业务开发中也包含了各种方，而以前看过的建模相关的资料，在中间件等基础设施上也没有太大的感觉，反而在业务技术领域发挥出了巨大的光芒。也发现越靠近用户的架构，随着企业的慢慢壮大会变得越来越重要。这个时候的我对架构认知是知道自己不知道了。
既然知道自己不知道了，那么就是要追寻它，曾经我和不少业务的研发同学讨论过架构是什么，撇去基础设施架构和物理架构等视角不谈(这些视角聊起来也是篇幅很长的)，我挑应用逻辑架构并从几个角度来尝试描述一下：
1)从架构的总原则的角度：尽可能简单(在当前场景下要尽可能简单便于扩展和维护)，但是不能太简单(相对而言太过于简单可能在场景上有所遗漏).
2)从架构的目的角度来考虑：既要解决过去的问题，也要解决现在的问题，还能适度解决未来的问题，这些问题既包含技术问题，更包含业务问题。
3)从形态之 2 维的角度来考虑：架构就是横的问题，和竖的问题。横就是分层，竖就是分区，横竖都有抽象的事情要做。
4)从形态之 3 维的角度来考虑：架构是三维的，在 x 轴和 y 轴上有横竖的问题，在z轴上还有粒度的问题。
可以看出，虽然我试图从以上几个视角对架构进行了描述，但是显然这些描述都是见仁见智的观点，是从某个角度来看架构。内心里我觉得自己提炼的高度是不够的，实践中的总结必须和业界的知识结合起来，我必须学习前人已经总结的体系。于是在不断的搜集资料的过程中，我发现在 ISO/IEC 42010:20072 中对架构有如下定义：
但这是一个广义上定义的架构，经过一些总结思考，我觉得实际上具体到我们日常的工作中，在不同的层次，会有更加精细化的架构分类。
在工作中我遇到不同职位的人从不同的角度来描述架构，但是我们鲜有能达成共识的，刚开始我也不知道为啥讨论不到一块去，后来经过一段时间的纠结和深入仔细的思考后，我发现很多时候大家描述的架构都不是同一个角度的东西，于是我尝试从如下几个角度划分架构的类别，以帮助我们在不同的场景和不同的人聊天时大家可以聚焦，明确我们到底是在讨论哪种架构，以提升沟通效率，并尽快达成共识，目前这个划分已经在我们团队基本达成共识。
值得注意的是，不管下面哪种分类的架构，都符合上一节总的架构的定义：模块(组件)+ 关系 + 约束 & 原则。
这个是产品经理最喜欢讲的架构，一般来说，讲我们有什么功能的时候，产品功能架构描述的是能做什么，受众群体一般是使用产品的同学。如果我们做软件设计时，不应该产出这玩意，而是应该产出应用逻辑架构和应用物理架构。但是一旦我们要对外宣讲我们的产品，比如我们的接口有啥用，应该怎么用，这个时候我们讲的应该是产品功能架构。
包含的内容：阐述产品功能模块的能力：比如一辆汽车，方向盘有什么功能，方向盘的按钮上各区域的功能是什么，仪表盘分成哪些功能模块，每个功能模块有什么作用，油门踏板有什么作用，刹车踏板有什么作用。但是也不排除有些高阶用户需要明确知道变速箱的齿比等信息，所以在产品功能架构图上也可以描绘出来。
命名：这里命名需要考虑如何取一个吸引人的名字(同时又能表达产品的能力)来吸引我们的用户前来使用，比如说以前经常有产品套用“纳米”，又有产品套用“绿色”等等。
用来分析业务，业务概念架构是指拥有哪些业务模块，且各自的能力是什么，这张图有助于我们分析和理解业务需求，也有利于产品经理分析业务。所以业务概念架构和业务概念模型都是用在分析阶段。
软件设计本身，模块，粒度，职责，复用，等等，在讲解软件设计的时候，使用的是这个架构图，这个架构图是通过系统模型和业务概念架构推导而来。所以系统模型和应用逻辑架构都是用在软件设计阶段。
包含的内容：阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等。如果拿汽车举例，那就是发动机模块中包含了哪些子模块(活塞，曲轴，连杆，缸体，缸盖，等等)发动机模块和变速箱模块之间的关联关系是什么，如何协同工作，和底盘的关联关系是什么，如何协同工作。发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
命名：这里的命名需要朴实无华，精准的描述出职责，华而不实反而让技术的同学无法理解这到底是什么玩意，导致实施的时候职责放错地方，挖下大坑让后人来填。
软件部署时的架构，这张图推导自应用逻辑架构，推导时重点逻辑架构如何落地，比如使用何种微服务容器，逻辑架构的模块落地时应该是 package，还是应用，也有可能是一组应用，是不是要跨机房部署，甚至跨国部署等等。还需要考虑稳定性，性能，成本等线. 基础设施架构
在日常的架构讨论中，有的同学经常谈架构的能力，有的同学经常谈架构的职责，那么能力和职责有什么区别?跟产品的同学打交道多了之后，发现产品同学很多都是讲能力，后来技术的同学也开始讲能力，而通常我们架构的同学原来讲的都是职责，两者有什么区别呢，我说说自己的理解：
是指一个产品能做什么，比如中台本身是一个产品，对使用中台的同学来说，我们应该讲中台的能力(其实是在讲中台这个产品的能力)。所以讲能力是讲给架构的使用者或者其他想了解的人来听的。
是指架构内模块的职责，用来指导开发，比如中台研发的同学，应该讲架构的职责，依赖，约束。所以讲职责是讲给研发的同学，讲给域内的架构师，讲给域内的管理者来听的，总的来说就是讲给架构的实现者来说的。
简单来说就是：能力是指产品的能力，职责是指架构内部的职责。如果架构本身也是一个产品需对外输出(如中台，或者其他技术框架作为产品输出)，则对外输出时，我们应该讲这个技术产品的能力(这个时候技术的同学也就开始讲能力了)。所以当我们讨论问题的时候，如果有的人在谈产品能力，有人在谈架构内部职责，那么显然已经不是在讨论同一个话题了，请大家务必注意区分这种情况，差之毫厘，谬以千里，鸡同鸭讲啊。
正如前面我们描述的架构分类所描述，有些架构和具体业务是无关的，有些架构是和具体业务息息相关的，比如说应用逻辑架构就是和业务息息相关，它来源于业务的抽象，甚至我们可以说：它是业务线技术架构设计中第一份产出。
架构的产出总的来说有两种方式，一种是自顶向下的方式来推导架构，一种是自底向上的推导方式，而且两种方式往往是相互结合来产出最合适的结果。而在业务线的同学，可能接触最多的是自底向上的推导的方式，自底向上的推导的方式也是本文中要重点讲解的架构推导方式。
自顶向下的推导的关键问题在问题定义，如果问题没有被准确的定义，那么自顶向下就无法推导出正确的结果。假设问题被准确的定义了，如何自顶向下推导呢?
分析阶段，也是我们常说的问题空间领域建模，关键的一步是业务概念模型的输出，而业务概念模型输出的前置条件是从需求中分解出合理的用例集合。
自顶向下推导的一个前置条件就是你需要知道猪长什么样，在架构上就是你需要知道这个架构的原来是是什么样子的，解决什么问题的。如果都不知道猪长什么样，那么就无从判断猪是不是适合当宠物了。此处需要有一定的业务领域理解力和领域经验(包含：客户的问题和痛点是什么，怎么分析出来的，当前的架构方案是什么，当前的架构方案是如何解决这个问题的，未来的架构方案如何更好的解决这个问题)。
这部分内容，我在 ICBU，村淘，一达通，菜鸟，AE 现场分享过。尤其是在 AE，一达通和菜鸟，相关的同学都拿出了当时的纠结大家很久的难题，我们一起使用了这样的方法很快就分析出了业务概念模型，并且对模块进行了简要的划分，形成概要的业务概念架构。经过大量的实战，效果是非常明显的。
归纳的意思是将所有的结果和想法合并，变成一种思维概念。或者让某个模型归属于某个已经存在的思维概念。且这些模型或者模块的职责不能超越这个高层次思维概念的边界。
其实是为了保证相近的职责模型聚拢在一起从而保证职责的高内聚，同时明确出来的两个子域的边界，保证模块和模块之间的低耦合。
业务模型图中，模型和模型连线(连线就是模型和模型连接线)数量除以模型的梳理得到的值比较大的，那么我们可以看做是内聚，这些连线比较紧密我们趋向将其放到一个模块中，连线不是那么密切。
JOB竞博 上一篇：「无代码·无边界」2023·76Day轻流无代码探 下一篇：人人都是平面设计？这10款设计神器请收好！