架构漫谈读后感

通过阅读架构漫谈了解许多关于架构的知识，现总结如下。

多人分工组成整体为了提高效率故而产生架构。

总结一下，什么是架构，就是：

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

架构实际上解决的是人的问题

桌子实际上就是抽象的一个过程。

以上通过几个例子，讨论了一下认识概念的误区，如何有效的去认识概念，明白概念背后的含义，以及如何利用对概念的理解，快速的进行学习。掌握了这些原则，会有利于帮助我们在架构阶段，快速的识别和定位问题。

一般来说，如果把真正的问题找到，那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。

识别问题主题

1.这是谁的问题？

2.有什么问题？

问题1会花费比较多的时间。

一旦问题1解决问题2的解决就会变得容易。

对于不能直接解决的问题，我们需要做架构的切分。即利益的调整。

切分的目的就是使各部分的工作量尽可能平均。以及工作量与利益的对等。

切分要非连续的，利益对等的并且不能超出自然人的负载。

切分不可使解决的问题发生变化。

切分过程即建模过程。

总结如下：

1. 架构的切分的导火索是人的负载太重。
2. 架构的切分实际就是对stakeholder的利益进行切分或合并，使得每个stakeholder的权责是对等的，每个stakeholder可以为自己的利益负责。
3. 架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
4. 架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。

软件开发以模拟人为目标。

性价比。

软件架构模拟人类社会分工架构。

以上通过简单的描述计算机和软件的发展历史，阐明软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。

本篇主要讨论架构需要解决的问题。

读完本篇后感触颇深，解决各种问题细分后十分详细，将主题问题分析透彻将有利于问题的解决，其中还设计到内部运营以及分工合作，架构的产生分类也十分具有新意。最后坐着解释了什么是软件架构，细读之后受益很多，架构是进化出来的。

以上只是针对单一的Service部署单元的分析，扩展开去，对于其他的部署单元也是类似的。每个单元的下一级都可以认为是Repository，每个单元的上一级都可以认为是User。这些实践在我自己的项目中都有用到，非常的有效，迭代的速度非常的快。很多人担心Business Model建不好，其实没关系，刚开始可以粗糙一点，后续可以慢慢的完善。这个架构已经隔离好了每个部分的变化对其他部分的影响，变化成本都在可控的范围之内。

以下试着分析一下：

1. 当技术所解决的问题和分拆出来要解决的问题，完全匹配的时候，这是最完美的。比如需要提供web要访问的service，很多MVC的framework就可以很好的满足这一点。而这个时候如果非要自己实现一个，很有可能就是重新发明轮子。

2. 当技术所提供的能力远远超过需要解决的问题时，往往掌握技术和维护技术会成为瓶颈。因为越复杂的技术，成本越高。如果自己实现一个仅仅是解决当前问题的方案，可能成本反而更低。这也是为什么很多大型的互联网公司不断地开源出来自己的技术的原因。而这些技术对于我们来说是否适用？他们原本是用来解决谁的问题的？什么问题？如果不清楚这些，就冒然采用，可能会导致更高的成本。

3. 当技术所提供的能力和我们所要解决的问题部分匹配时，还是要看成本。比如当我们需要一个锤子的时候，手边正好没有，但是却有一只高跟鞋，勉强也可以替代锤子。但是长期来看，这么用不划算，因为高跟鞋的价格比锤子高很多，耐用性差很多，维护成本也高很多。

　　所以，准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。