概念是为解决某一特定问题的解决方案所起的名字，因此由概念本身可以帮助架构师在了解未知领域时，更快的嗅到用户所处的领域的问题的线索，概念本身是精炼化的，所能展露出信息也是有限的，因此需要以用户表达的需求和所处领域为背景，猜想概念的来源，多一些较真，多一些为什么，就像桌子和柜子，同样都可以都可以用来吃饭，都可以起到放东西的作用，但是就事实而言，你不会在餐厅买一个柜子用来吃饭，这就说明刚刚的猜想是有问题的，产生了矛盾点，但是在没用过桌子和柜子的人眼里，他们所起的作用是一样的，因为他们没有足够的细节去洞察这两物体在这个使用场景下的区别，而对于大多数架构师来说也是如此，不可能提前了解到用户领域的细节，而用户在无引导的自然表达下，并不会吐露出多数细节。所以我们要以一个未知领域探索者的身份去尝试理解用户的领域，对每一个概念都不求甚解，直到在用户的帮助下，形成一个网状图，抛开常识，想一张白纸一样，对每个概念进行重定义，当定义和用户的认知重合的时候便确定好一个点，进而形成一张图。
人类社会是一个利益相关体，同时也是服务于生活的架构，而团队也是利益相关体，可以参考社会，团队中每个人都想过的舒服，但工作注定不是轻松的过程，唯一的慰藉就是做自己擅长的事，做喜欢的事，或者做不喜欢的事但得到更多的钱，这本质就是当实现权力和义务对等时，成员就可以以相对正向的速率前进，架构应当是树状的，有负责范围大小的组织者和工作者组成，每个人得到自己的职责并可以交给下级做的部分向下切分给下级，因此能力越强，分给下一级的部分越少，树的层数也越小。架构不应当是图，虽然在工作时，别人做了我们的工作会让我们压力变小，但是同样权利和义务对等，当出现问题时，依然要承担责任，也对有些人来说也失去了表现和锻炼的机会，对于整体而言，会影响各部分的沟通，因为他增加耦合度，减少了聚合度。
如同前面描述的架构的定义，软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。阐明软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。
为什么会有这个对时间的恐惧和压力呢？这是因为我们把完成自己的工作当成了我们的最大利益。如果别人的问题没有真正的解决，必然会觉得付出的报酬不值得，我们的利益实际上是受损失了。这和我们所以为的恰恰相反，因为我们所能得到的工作只会越来越少，别人会越来越不愿意依赖于我们。每个成员加入团体的原因或许不在于自己是否能做自己擅长的事，而是能不能用自己擅长的来换取别人帮忙做自己不擅长的事，只有自己做不到事情才需要帮助，团队中的利益网，是其他人指向自己形成的，本质是需求，而不是自己指向他人形成的，本质不是付出。当一个人对于团队产生了依赖性，也说明了团队的内聚性提高，成员会自发的为团队付出，会因为团队而主动承担责任，这全都源自于团队能为他提供他想要的东西，可能并不只局限于金钱。
因为技术和语言，都是用来识别和解决所服务的主体的权责，保护并提升所服务的主体的权利的。特别对于软件领域来说，必须明白软件本身是怎么回事，解决什么问题，还要解决软件所服务的对象的领域本身是怎么回事，解决什么问题，这就要求更高了。语言和技术应该是随手拈来才对，对于架构师这些都是工具。学习技术和语言，如果明白了这些技术和语言要解决的是谁的问题，什么问题，学起来是非常快，非常容易的。
“其实刚开始一般是硬着头皮去克服对时间的恐惧和压力的，一点自信都没有。但只要做成功了一次（只要真的舍得这么去做了，想不成功也很难！），自信就开始慢慢建立起来了”
标签：读后感,架构,漫谈,用户,自己,利益,软件,团队 From： https://www.cnblogs.com/miutic/p/17133973.html