老师上课围绕《架构漫谈》前四篇图文并茂的讲解了何为架构，架构的基础，以及识别问题和架构切分这些作为架构师需要了解的最基本的知识。现在要讨论的是软件架构师应该如何工作，如何更好的，更快的，更有效率的工作。
要想做好一个工作就应该了解这个工作最基本的需求是什么，而作为一个软件架构师就必须应该清楚的知道自己的职责是什么。也就是说，软件架构师需要负责什么工作，要解决什么问题。以下内容，就《架构漫谈》为中心，一步步细谈软件架构师应该如何工作。
《架构漫谈》第五篇介绍了什么是软件。以及软件的发展，始终贯彻成本为王。社会的发展以利益为核心，软件的发展也不例外。软件的存在是机器模拟人的工作，为用户提供更快捷方便的服务。而软件的开发，更是需要低成本。
说到软件开发，绕不过的一个职业是软件工程师，然而软件工程师本身的培养就比较难，同时行业知识也要靠时间的积累，这样就远远超出了软件工程师的能力了。所以软件开发就开始有分工了，行业知识和业务的识别，会交给BA，系统的设计会交给架构师，设计的实现交给架构师。
究竟那些算是软件架构呢？
-
软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。
-
每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。
《架构漫谈》第八篇从架构角度看如何写好代码。我们已经知道，软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。
我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关stakeholder的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。
《架构漫谈》第几篇详谈了软件架构师如何工作。
通过理清技术，业务和架构的关系这个方面透彻的说明了架构师在平衡架构业务时所要注意的方方面面。
技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：
-
技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
-
有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。
一般是先有技术，才会有架构。这些其他技术，是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术组合在一起。在解决主要问题之后，再开始逐渐的分拆为更为细粒度的技术。
而这个细粒度的技术往往不会和业务的主要目标发生直接的关系。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。很多人把这个过程称为架构的进化，我更愿意把这个过程称为技术的进步所导致的新的架构分拆，因为这个过程内在的动力，更多的是来自技术对业务问题的解决。
那么，架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。
2018-03-07
