50 | 架构实战：架构设计文档模板

很愉快的一段旅程。😁😁😁

专栏结束啦 走上架构的路才开始 一路走来，繁花似锦 当然，也有曲折和泥泞 这就是旅行吧 架构之路如此，人生也一样 在这路上，有人走的快，有人走的慢 不过不放弃就好 他人的人生你替代不了，你的别人也只能欣赏 华仔就像一个走过此路五百遍的导游 他就轻驾熟，带着我们翻山越岭 看天空的静谧 听风谷的传奇 一路相伴，感谢有你

好详细的模版，最怕的就是写文档。文档就是属于写出来看的人不多，感觉写了没用，到关键时候又能发挥作用的那种

专栏订阅得早，一直没坚持看完。从9月9日到今天10月20，近40天的时间内走完了第一遍。最起码心里有个底，架构是什么，解决了什么，架构带来了哪些复杂度，架构的遵循的原则等等，感谢华仔。看完第一遍不是结束，而是开始，一定会应用在实战中，后续肯定会再次拜读

画架构图用什么软件？有推荐吗

跟着华仔学习架构，晦涩难懂的内容变得清晰明了。跟着课程一路走来，感谢有你！为加强领悟和学习，稍后我会再读一遍。也期待着华仔新的架构课程快快上线，坐着老司机的特快号，继续徜徉在计算机的思维时空中。

整体看完了，感谢作者。我在实际工作中有一个问题一直很迷惑，请华仔帮忙解答。 我们服务内部采用的是微服务架构的方式，规定了服务间、对APP 的接口规范。也有网关层负责代理。但是随着业务复杂，服务端的接口越来越多，APP 希望服务端有一个聚合服务，也就是一个大的api ，可以统一编排需要的返回值。并且只愿意和api 层的开发人员打交道。但是，如果这样的话，api 这个服务又会变得特别大。并且还非常无聊。以前就有同事因为api 事杂，收益小离职！请问华仔，这种问题应该怎么解决？我现在采用的是按照业务拆分聚合层，类似于前文中说的虚拟服务组。

花了三天，终于赶在课程有效期内看完了，(不好意思我白嫖了😂)真是收益良多。回顾以前做过的项目，很多都理解了，要是能早点看到这本书，当初就不会那么狼狈了。 在学习的过程中，一直有一个问题：项目经理和架构师不是每个公司都有吧？我在之前的一家公司，光做技术的就有三四百号人，没听说有项目经理或架构师。 我们公司有两种管理方式，按技术分：最底层是后端开发，直接上级是开发组长。按业务分：最底层是业务，往上是一个团，团内的同学只负责团内的业务。团业务是产品直接负责的，即产品也是团长。现实是产品既负责业务也管理技术(很多产品都是技术转过来的)，但是由于产品的业绩来自业务而非技术，所以很多时候产品会选择牺牲技术换取业务，而作为开发的我们又很难说动产品，技术组长也只是个摆设(技术组长更多负责公共组的内容，即没有入团的业务)。 一次开会，有个同学问部长(管理多个后端组)，公司是不是缺少项目经理，部长说：“面对业务的快速迭代，项目经理能做的工作有限，因为需求从提出到上线只要一两天，所以你自己就是项目经理”，问题是我们又没有项目经理那种权利，如何去和高高在上的产品抗衡呢？架构设计就更别谈了，无奈我们只能天天加班处理故障

文档模板很棒

极客时间第一门学完的课程，在这里要感谢老师