架构漫谈之感想

Posted 2020-09-02 九块九毛九

      把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。

      要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。架构实际上解决的是人的问题，而概念是人认识这个世界的基础，自然概念的认识就非常的重要。做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。

      做好架构首先需要做的就是识别出需要解决的问题。我们平时的一些口头语可能缺乏主语，而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果闹出大笑话。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。找出问题的主体，是做架构的首要问题。架构师要解决的，基本都是别人的问题，而且架构师要认识到：发现问题永远都比解决问题来的更加重要。从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。识别出的个别问题，需要通过架构的切分来进行相应调整，也就是利益的调整。切分的过程就是建模的过程，每次对大问题的切分都会生成很多小问题，每个小问题就形成了不同的概念。架构切分的输出实际上就是一个系统的模型，对于一个整体问题，有多少的相关方，每个相关方需要承担哪些权利和义务，不同的相关方是如何结合起来完成系统的整体任务的。架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。

      架构的出现是有原因的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。当我们说软件架构的时候，一定要清楚是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。

      并不是做架构的就是架构师，架构师必须具备一定程度的自信，去真正的发现问题的主体，识别真正的问题，并把这个行为变成为自己面对问题的第一反应。架构师要去平衡别人的利益，甚至会调整别人的利益，必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。

      如何把架构的思考进行落地，细化到我们代码的实践当中，尽量不要让代码成为系统长大的瓶颈，降低架构分拆的成本。我们的代码应该分为两部分：表达业务逻辑的代码和对用户提供访问并保存业务逻辑运行结果的代码。假期了解了SSH框架，集成SSH框架的系统从职责上分为四层：表示层、业务逻辑层、数据持久层和域模块层。其中使用Struts作为系统的整体基础架构，负责MVC的分离，在Struts框架的模型部分，控制业务跳转，利用Hibernate框架对持久层提供支持，Spring做管理，管理struts和hibernate。具体做法是：用面向对象的分析方法根据需求提出一些模型，将这些模型实现为基本的Java对象，然后编写基本的DAO接口，并给出Hibernate的DAO实现，采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问，最后由Spring做管理，管理struts和hibernate。

      技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。