《架构漫谈》读后感

这几天，读了老师推荐有关架构的一篇系列文章《架构漫谈》，其中通俗易懂的语言，风趣幽默的风格，形象明了的对比形式让我对架构有了更进一步的了解。

当阅读《架构漫谈》这本书后，我深刻认识到了软件架构的重要性和具体的实践方法。

首先，在架构设计的初期阶段，需确定软件的整体结构和分层，并根据软件的特性和功能来确定各层次之间的关系和交互。其次，需确定技术栈和技术架构，如前端、后端、数据库等技术的选择，以及设计可扩展性和可维护性的技术架构。此外，还需要了解不同类型的架构，如微服务架构、事件驱动架构等，并根据实际情况选择合适的架构。

其次，需要明确不同部署单元之间的职责，明确每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：表达业务逻辑的代码，对用户提供访问并保存业务逻辑运行结果的代码。应该保证业务逻辑只存在于Business层，而Service、Glue Code、Repository等层次不允许存在业务逻辑。

此外，架构设计需要实现业务与技术的平衡，技术选择需要以业务需求为出发点，同时要考虑软件的可维护性和可扩展性。此外，应该避免将架构和技术混淆，应将架构视为全局的计划和技术的实现手段，不应该将技术当做架构的全部。
最后，需要给架构师实权，架构师应该是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。如果架构师只能够通过建立某些流程来行使架构师的权利，反而会造成很多内部不必要的冲突，最终都会导致这些流程流于形式，得不偿失。

综上所述，《架构漫谈》这本书为我们提供了一些架构设计的思路和方法，这些方法不仅能够帮助我们更好地完成软件开发任务，还能够帮助我们实现软件质量和可维护性的提升。

作者通过一个人群的分工配合的例子引出了他对架构的一个定义：把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。再总结一下，架构是一个有不同部分构成的一个整体，且不同部分之间是相互联系的。架构是由人类自身的缺陷和出于目的而产生的。人类自身的能力和专注力有限，而想要的目标却往往是一个人不能达到的，于是不同的个体联系成一个整体，通过个体之间的协调和沟通而达到一个共同的目的，使得整体的存在有明确的意义。

       很多时候问题的产生都是因为沟通的误解，或者主观上有很多不必要的利益诉求导致的。但是总还有一部分确实是有问题的，需要做调整，那么就必须要有所动作，做相应的调整。这个调整就是架构的切分。所以切分是利益的调整。切分也需要有原则，这四个原则是：连续时间内的活动不能切分；权利义务对等；不超出一个人的负载；对外部透明。总结下来，架构的切分的导火索是人的负载太重。架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。