架构

1.如何做好架构

一.识别问题，找到问题主体；
找到就解决了80%的问题，架构师要自觉，发现问题永远比解决问题来的更重的。

一般从问题暴露点一点点去溯源查找，最坏情况就是我们时间能力有限，实在无法定位查到谁的问题，比如系统故障，也就意味我们根本无法解决的问题，这时更好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响范围，留出时间和空间去识别真正问题。

架构师的能力大部分会体现问题的识别上这是谁的问题的识别上？

二. 架构切分，本质上是利益的调整
在识别出谁的问题之后，大部分问题都迎刃而解了，有一部分确实有问题，需要调整这个 调整就是架构的切分；
1.简单来说，架构的切分导火索是人的负载太重，
2.架构的切分实际就是对(stakeholder)利益相关者的利益进行切分合并，似的每个stakeholder的权责对等，为自己的利益负责；
3.架构切分最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进；
4.架构切分结果一定是一个树状。这也是为什么会产生分层，层数越多沟通越多，效率越低，分层越少越好，尽量保持一颗平衡树，才会让整个系统效率最大化。

为什么需要架构切分？切分就是利用调整
所有切分调整都是个人利益的维护，当人们认识到主动切分一个系统的时候，我们就不能忘掉利益这个原动力，所有决策都不能够违背这一点，确定问题主题就会发生以下几种情况：
1.某个人或利益相关负载太重；时间上的负载太重，空间上的负载太重，本质上还是时间上的负载太重。
2.某个或者利益相关人权利和义务不对等，总结；
  架构的切分的导火索是人的负载太重。
架构的切分实际就是对stakeholder的利益进行分切或合并，使每个stakeholder的权责是对等，每个stakeholder可以为自己利益负责。
架构切分最终结果都会体现在组织架构上，只是这样才能让架构落地并推进。
架构切分的结果是一个树状，这也是为什么会产生分层，层数越多沟通越多，效率越低，分层要越少越好，尽可能变成一颗平衡树，才能让整个系统效率最大化。

软件架构要解决什么问题？

一.业务问题
1.具体现实生活状态下，没有软件的时候，所解决问题主体是谁，解决的是什么问题，如何解决，如何运作的？
二.计算机问题
1.如何把现实生活用软件来模拟？
2.模拟出来的软件需要那些硬件设施才能够满足要求？并且当访问量越来越大的时候能否支持硬件慢慢长的，性能线性扩展？
3.因为硬件是可能会失效，软件如何在硬件失效情况下，任然能够保持可用性让用户能够不中断的访问软件提供的服务？
4.咋样收集软件产生数据，为下一阶段的工作提供依据？

究竟哪些算软件架构呢？
软件因为流量增大而分析成不同运行单元，在不同机器上部署所形成架构属于软件架构，每个运行单元为了让不同角色的人，比如前端，业务数据存储等能够并行工作，所分成的代码架构也属于软件架构。
所以当我们说软件架构的时候，我们一定要清楚，究竟说的是部署的架构还是代码架构，软件架构的落地，需要软件组织架构和流程来保障，离开这个软件架构就是空话。
另外很多人讲，架构是进化出来的，架构实际上是在量不断的增大，超过单台服务器的容量逐渐的分拆，同时导致超过单个人员能力，工作人员不断增多，工作内容不断分拆形成这本身就是架构意义所在，不管咋样分析，所达到的目的没有任何改变就是完成业务在计算机中的虚拟化。

架构师没有话语权还架什么构！！
1.架构师是要去平衡别人的利益，甚至会调整别人的利益，一旦架构师是全心全意为别人利益服务，自然而然的架构师就拥有强有力影响力，肯定会是一个leader,但只是名义上的leader是没用的，不能完全发挥架构师能量.
2.架构师必须是一个组织领导人，。有权利调动这个组织的架构，才能够更好发挥架构作用，更好把利益的调整落实到实处。好多公司设有架构师职位但并不具备有架构的权利，形同虚设。
3.架构师只能建立某些流程来行使架构师权利，比如强制架构review,反而会造成内部不必要的冲突，最终都会导致这些流程流于形式得不偿失。
4.反过来既有架构师能力的组织领导人，一定是一个很好的领导，这个组织一定很健康向上的，因为每个人的权利和义务比较均等，并且这类领导对组织成员权利和义务非常敏感，会及时调整组织架构，在问题发生之前就解决了。
5.　这样这个组织就会具备更好的抗压能力，能够更好的为这个组织的客户服务，这个组织的成员内心一定都是比较平衡的，每个人的能力都能够得到比较好的发展。当然读者可能又会说，这不是管理学的东西吗？ 是的，但也是架构的问题。
　　所有架构的核心就是组织架构。或者也可以这样说，一个合格的组织领导人，一定必须是一个合格的架构师。

架构师和技术？

　很多人会问，特别是做软件行业的，架构师是不是需要学习技术，甚至是学习语言？ 如果一个架构师还有这个困扰—就如问这个问题的人，说明目前还不具备做架构师的能力，或者说还不具备对自己领域 -- 哪怕是技术领域 -- 的自信，更别谈业务领域了。
因为技术和语言，都是用来识别和解决服务的主体的权责，因为技术和语言，都是用来识别和解决所服务的主体的权责，保护并提升所服务的主体的权利的。特别对于软件领域来说，必须明白软件本身是怎么回事，解决什么问题，还要解决软件所服务的对象的领域本身是怎么回事，解决什么问题，这就要求更高了。

从架构的角度看如何写好代码？

　我们经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。
1.表达业务逻辑的代码，很多人把这部分叫做Domain Logic或者Domain Model这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为抽象而成。
2.对于用户提供访问并保存业务逻辑运行结果的代码。计算机状态保存有缺陷，本机保留业务运行结果有很大问题，一般都在外存储设备上保存，也便于扩展。
3.我们真正想快速完成代码工作，就要克服自己对时间恐惧，真正去研究业务问题，相关stakeholder的利益，把这个变成我们的习惯，写代码时候应该出现逻辑的地方出现逻辑，让不该出现的地方不出现，一旦不该出现地方出现逻辑，那就马上意识到这个地方就是坑，这个问题一定和业务的分析不透彻有关系。

理清技术，业务和架构的关系

1.技术就是为了解决业务的问题而产生的，没有业务技术就没有了存在的前提；
2.有了更好的技术，效率更差的技术就会慢慢被淘汰，消失，一切都遵从人类利益的诉求也就是业务，有人会问，不用钻木取火了，但弓弦加速转动木棍还可以用？没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。
　　所以技术与技术之间，有两种关系：
在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。

技术人员和业务人员关系；
1.技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的，业务也是负责某一部分的业务，也不是和业务的主要目标直接对应，都是树的分支节点，只有直接解决业务问题的技术，树的根节点，会和业务直接相关，所以一旦产生冲突，一般必须两个根节点碰面才能解决问题。
2.在软件各行业这个根节点技术就是软件，这也就是为什么架构师要认识什么叫软件，软件解决谁的问题，什么问题，软件本身又是咋样分拆，才能更好组合不同技术，完成业务目标，而软件里面和业务直接相关，只有Business Domain这一部分。