新学期，在老师的推荐下，我精读了《架构漫谈》九篇博客。刚好对本学期开设的软件架构这门课程有了一个学习的方向，同时，对于软件架构知识体系有了全面的了解。下面是我在阅读过程中的几点体会。
架构漫谈逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题。首先，要搞清楚什么是架构，什么又是软件建构。什么是架构？我简单的理解为一种解决问题的模板。深入了解发现架构是为了解决由人执行的工作、解决分工合理明确、提高生产效率的问题。架构对提高生产效率是很有帮助的？那么，怎么提高生产效率呢？除了科学技术带来的生产力的提高之外，剩下就是人的问题了。由于每个人的时间精力有限，并且在同一时间一般只能专注做一件事，因此就有了分工。分工的合理明确就提高了生产效率。由此引用架构漫谈中的定义就不难理解了。架构是根据要解决的问题，对目标系统的边界进行界定，并对目标系统某个原则进行切分，切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。并对这些切分出来的部分，设立沟通机制。
架构的产生需要五个条件同时成立。
-
必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）
-
每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）
-
每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见2，从而缩短时间）
-
人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）
-
目标系统的复杂性使得单个人完成这个系统，满足条件2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠， 并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）
如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么最多只能成为一个工匠，无法成为一个架构师。因为这个过程解决的还是自己的问题，并没有时间的压力，可以随意什么时候做完都可以。 要成为架构师，必须要能够看清楚，我们要解决的是别人的问题，不是自己完成工作的问题。因为仅仅是完成了自己的工作，也并不一定就解决了别人的问题。如果别人的问题没有解决–即使我们认为自己的工作完成了–我们的工作实际也没完成，因为我们工作是否完成，是别人说的算的，不是我们自己。只有做到这一点，才能在自己所服务的领域建立起自信，成为一个合格的架构师。 由架构出现逻辑，逻辑出现问题，必然导致架构无法快速的横向扩展和分拆，并且增加了修改的成本，这些是不符合开发人员以及业务的利益的。 要学会理清技术、业务和架构的关系：我们要学会怎么处理业务、技术还有架构的关系。那么什么是技术要解决的是人类自己的问题，这就是业务，实际就是人类的利益。架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。
1.什么是软件架构
软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。
所以我们经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。
2.架构师思维
抽象
分层
分拆（或划分职责）
建立内部流程
学会了技术并不代表能够解决问题
3.步骤
学习业务知识
对业务进行建模
4.架构师的前提条件
把完成别人工作当成自己的最大利益，帮助别人解决问题
技术领域、业务领域