架构漫谈读后感

今天阅读了王概凯的架构漫谈,下面我从以下几点来表达一下自己的认识.

第一节讲的是架构的概念及其背景，文章首先引用了Wikipedia上的定义，然后通过早期人类分工合作的例子，解释了为什么需要架构。架构将一个整体切分成不同的部分，并通过建立不同部分之间的沟通机制，使得这些部分能够有机地结合为一个整体，完成目标系统的所有工作。最后，文章以建筑为例，更深入地解释了架构的概念，并给出了作者的定义：根据要解决的问题，对目标系统的边界进行界定，并按照某个原则将目标系统切分成不同的部分，建立不同部分之间的沟通机制，使得这些部分之间能够有机联系，最终完成目标系统的所有工作。

第二节讲的是概念及其与架构的关系。文章指出，架构实际上解决的是人的问题，而概念是人认识这个世界的基础。每个概念所解决的，都是人们遇到的某个特定的问题，我们将解决问题的解决方案命名为一个特定的概念。此外，文章还讲解了抽象的含义，即将不同概念的相似部分合并成一个新的概念。因此，通过概念的抽象和合并，我们能够更好地理解和解决问题，同时也能为架构设计提供帮助。

第三节讲的是架构识别，也就是说，在构建架构之前，需要先识别需要解决的问题。在识别问题时，一个很大的难点是搞清楚问题的主语，也就是问题是由谁引起的。由于很多概念缺乏明确的主语，所以我们需要在沟通中尽可能明确主语，才能有效地解决问题。当我们确定了问题的主语后，问题的边界也就随之确定了，接下来才能够有效地解决问题。

通常情况下，我们可以从问题的表面出发，逐步寻找根源，以确定问题的主语和性质。但如果时间或能力有限，无法准确定位问题的主语时，我们可以尽可能地隔离问题的影响，降低问题带来的成本，以争取时间和空间去识别真正的问题。

第四节，作者提到了如何做好关于架构的切分的问题。我们要非常清楚，所有的切分调整，都是对相关人的利益的调整。这是因为维护自己的利益，是每个人的本性，是内在的驱动力。社会的分工是必然的，因为每个人都希望能够把自己的利益最大化。在这个模式下，每个人必须要舍掉自己的一些东西，才能够得到更多的东西。因此，在架构设计的过程中，我们必须要考虑所有相关人的利益，寻找最优解决方案，让每个人的利益都得到最大化。这就要求我们在切分架构的时候，要考虑到各个部分之间的依赖关系，以及不同部分之间的职责边界。同时，也需要考虑到未来的扩展和变化，避免在未来的某个时刻需要进行大规模的重构。因此，切分架构需要谨慎，需要考虑全面，需要做好充分的准备和规划。

在第五节作者指出了软件的本质是通过计算机将人类日常生活中所做的事情虚拟化，使得人们可以通过计算机的输入输出设备来完成日常工作和与他人的沟通。软件一直以来的动力都是为了模拟人类和社会。作者提到了几个例子，比如模拟大气运动，模拟人类社会，模拟交易以及现在流行的VR和人工智能等等。作者认为，模拟的对象越来越高级，难度越来越大。软件的主要目的是将人类的生活模拟化，提供更低成本、高效率的新生活。因此，软件的发展依赖于人类的生活知识。

在第六节指出在软件架构中，需要解决的问题不仅仅是业务问题和计算机问题，还包括可维护性、可扩展性、可重用性、安全性等问题。因此，一个好的软件架构需要考虑到这些方面的问题，并在架构设计中进行充分考虑。此外，对于不同的软件系统，其架构也有所不同，需要根据具体的业务需求和技术实现进行相应的调整。因此，软件架构设计是一项相当复杂的任务，需要设计师具备丰富的经验和技能。

在第七节中，作者强调了架构师必须拥有实权，才能更好地发挥作用。许多公司虽然设置了架构师职位，但没有赋予其实权，这样就形同虚设。架构师只能通过建立某些流程来行使架构师的权利，例如强制架构review，但这可能会导致内部不必要的冲突，最终流于形式，得不偿失。因此，公司需要确保架构师拥有实际的权力，以便更好地指导组织架构，实现利益的调整。

在第八节中，作者提到了如何从架构的角度写代码。根据每个部署单元所承担的责任，可以将代码分为两类：表达业务逻辑的代码和对用户提供访问并保存业务逻辑运行结果的代码。其中，业务逻辑应该只存在于Business中，而Service、Glue Code、Repository等部分则不应该存在业务逻辑。这样的分层可以使得代码更加清晰，易于维护和扩展，并且可以更好地符合面向对象的设计原则。同时，作者还建议在设计架构时要充分考虑系统的可扩展性和灵活性，避免出现瓶颈和难以维护的情况。

第九节作者讲到架构师需要理解业务需求，并且将其转化为系统设计，以便于技术团队实现。因此，架构师需要了解各种技术，但技术并不是架构设计的全部内容。架构设计需要考虑许多因素，如系统的可扩展性、可维护性、性能、安全性等。同时，架构师还需要考虑未来的业务增长和技术演进。在进行架构设计时，需要全面考虑技术、业务和架构的关系，以便创建一个可持续发展的系统。

技术与技术之间，有两种关系：一种是在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。另一种是一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。

　　架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成