架构漫谈读书笔记

      在我看来架构就是根据人们的需求即需要解决的问题把系统按照某种原则分离开来，但是这些部分还能够联系在一起，使得系统不至于分散。但是并不是做软件的时候就得进行架构，如果只有一个人进行开发就不必进行架构。

       对于架构来说是解决人的问题，概念是人认识这个世界的基础，所以概念在架构过程中也非常重要。概念属于人认识这个世界并用来沟通的手段，它的另一种说法是名相。实际上概念解决的还是人遇到的某个问题，解决问题的方案名字叫做概念。所以做好架构首先要正确的认识概念，然后发现概念背后代表的问题，进而认识目标领域所需要解决的问题。在架构过程中抽象这个词用到的也很多，它是把不同的概念的相似部分合并在一起，形成一个新的概念，是一个分类的过程。

      做好架构的第一步就是识别问题，而对于问题的识别主要的就是识别问题的主体和核心。当遇到问题时要问两个问题：1.这是谁的问题？2.有什么问题？，以此来确定问题的主题和核心。还有就是架构师在架构时解决的都是别人的问题，对于别人给架构师提出的问题就不能算是问题，因为能够提出问题就肯定有他自己对于该问题的解决方案，所以架构师还要发现隐含的问题。

       对于架构的切分也要非常严谨，因为架构的切分调整就相当于是对相关人的利益的调整，切分时要将时间上连续的动作，切分成时间上可以并行的动作，在空间上横向扩展，切分的过程就是建模的过程。所以切分有一系列的原则：1.必须在连续时间内发生的一个活动，不能切分；2.切分出来的部分的负责人，对这个部分的权利和义务必须是对等的；3.切分出来的部分，不应该超出一个自然人的负载；4.切分对于整个系统的外部应该是透明的。切分之后的结果是一个树状，所以会产生分层，而分出来的层数越少越好，而且最好是一个平衡树，这样才能让整个系统的效率最大化。

      对于软件架构也是慢慢在开发的过程中有意识的迁移切分演变而来的，软件工程师的职责在软件的发展历史中拆分成不同的角色，形成了独特的架构体系。软件架构分为两种：1.软件因为流量增大而分拆称不同的运行单元；2.每个运行单元为了让不同角色的人能够并行工作，所分成的代码架构，也属于软件架构。软件就相当于是将现实生活模拟到计算机中。在软件开发过程中因为任务比较多，所以要将需要把所做的事情列出来进行分析。首先要虚拟化业务，然后查看代码如何运营，最后需要组织架构来组织代码的编写和运营；这三步都需要列出需要做的事情然后进行分析。软件架构的类别由很多因素决定：用户流量，时间要求，参与人员等。

      从架构这个过程自然衍生出架构师这个职业，因为架构师是要解决别人问题的，所以首先要克服对时间的恐惧，这样才能更好的解决问题。克服恐惧之后就要开始思考是谁的问题。有什么问题。然后找解决方案的时候要考虑别人的利益，甚至调整别人的利益。因为解决问题的过程中架构师必须清楚软件本身是怎么回事，解决什么问题等，对于架构师本身的要求就提高了，所以最好学习一些技术和语言这样可以使得架构过程更加轻松，成本也更低。但是对于技术的种类也不要过多，过多之后往往会影响在项目中的使用，会对技术的选择产生更多的干扰。

      在架构角度来说写好代码需要将代码明确的拆分成两个部分：1.表达业务逻辑的代码2.对用户提供访问并保存业务逻辑运行结果的代码。因此软件总分成了Service、Glue Code、Business和Repository几个责任，这几个责任组成的仍是树形架构，其中只有Business中有逻辑。在service中根据角色来划分，避免不同角色修改时互相影响，所以尽量不重用这段代码。而Business Model则必须重用。

       在架构过程中技术、业务和架构之间的联系非常密切；技术为了解决业务的问题产生，技术之间则是优胜劣汰的关系，技术和架构则是先有了技术才有了架构。

       在我看来在架构过程中，架构师起着至关重要的作用，所以架构师要严格要求自己，然后学习相关的技术，解决用户的问题，在过程中一定要先询问自己这是谁的问题和这个问题是什么，只有这两个问题确定了架构的准确性和架构的流程的进行才能更加的有保障。