首先，我们要明白一个道理，什么是架构？

王概凯的架构漫谈中说道，根据要解决的问题，对目标系统的边界进行界定。并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。并对这些切分出来的部分，设立沟通机制。使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。就是架构的含义

那到底为什么会出现架构呢？

博客中提到，为了满足人的越来越高的需求，提升质量，减少时间，更有效率的切分空间，并且让空间之间更加有机的进行沟通。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

而架构的出现是为了解决人的问题。

让我来举个例，使用MVC模式分析自己家庭架构。

模型（Model）：模型代表应用程序的数据和业务逻辑。在家庭中，这可以是家庭成员的个人信息、日常活动、家庭预算等。
举例：家庭成员的生日、学校成绩、健康状况等信息可以被视为家庭的模型。

视图（View）：视图负责显示用户界面和呈现数据。在家庭中，这可以是家庭成员之间的交流、共享的空间，比如客厅或共用电子设备。
举例：家庭的客厅可以被看作是一个视图，家庭成员通过这个视图共享信息、交流。

控制器（Controller）：控制器协调模型和视图之间的交互。在家庭中，这可以是家庭规划、家庭成员间的沟通、决策制定等。
举例：父母可以被看作是家庭的控制器，负责协调家庭成员的活动、制定规则和决策。

那么如何做好架构的识别问题呢？

找出问题的主体，是做架构的首要问题。这也是王概凯一再强调的，我们要解决的问题，一定都是人的问题。更进一步，架构师要解决的，基本都是别人的问题，不是自己的问题。再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。当明白了问题的主体，我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。这个就比较直接了，常用的方式就是直接面对主体进行访谈，深入到主体的工作生活当中，体验并感受这些问题，甚至通过数据的反馈来定位问题。这个大家就比较熟悉了，我就不展开了。一般来说，从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。最坏情况就是当我们时间或者能力有限，实在是无法定位出是谁的问题的时候，比如系统出故障，也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响的范围。给我留出时间和空间去识别真正的问题。

通过生动的比喻和案例向读者介绍了架构的基本概念，使得原本晦涩难懂的技术术语变得生动易懂。他将架构比喻为一座大厦的蓝图，强调了在软件设计中提前规划和考虑整体结构的重要性。这让我意识到，良好的架构不仅仅是技术实现的问题，更是对整个系统的深刻理解和全局把握。

其次，书中对于不同类型的架构模式进行了深入的剖析，包括单体架构、微服务架构等。通过比较不同架构的优劣势，读者可以更清晰地了解在何种情况下选择何种架构。这种理论联系实际的方法，让我在实际工作中能够更加明晰地抉择合适的架构方案。

此外，作者还涉及了架构设计中的一些通用原则，如模块化、可伸缩性、灵活性等。这些原则不仅在软件开发领域有着广泛的适用性，也对我个人的思维方式和解决问题的方法产生了积极的影响。通过遵循这些原则，我们能够更好地应对变化、提高系统的可维护性，并为未来的扩展奠定基础。

最后，书中还探讨了架构师的角色和责任。架构师不仅需要具备深厚的技术功底，还需要具备良好的沟通和领导能力。这使我认识到，在团队协作中，一个合格的架构师需要成为技术和业务之间的桥梁，引导团队朝着共同的目标努力。