原文：聊聊架构
作者 | 吴京润
最近刚读完《聊聊架构》，我也多次在微信朋友圈推荐过本书；推荐的原因不是因为行文优美流畅，也不是因为它是什么名篇巨著，仅仅是因为它回答了很多困扰我许久的问题，让我重新思考软件工程、架构和软件本身。有人因为我的推荐去读这本书，后来又说本书行文啰嗦，干货不过50页，所有内容在软件工程前三章都能找到，而软件工程和架构也绝对不是50页能讲清楚的。
这段话让我想起自己做程序员以前的经历，我也读过软件工程相关的书籍，也许是我悟性太差，始终不能把书中的内容与实际的软件开发结合起来，书中的内容似乎读懂了却不知道怎么运用到软件开发工作当中。当然我是野路子出身没有接受过系统的软件工程相关的教育，大概跟这个也有关系。直到我读到了本书，相见恨晚。“软件是虚拟世界的虚拟人代替真实的人完成工作，只是这些虚拟人没有意识和人格，需要由真实的人像操作提线木偶一样操作它们。”我在读本书时，这句话一直萦绕在头脑中。世间一切都有生命周期，大到宇宙，小到粒子，从物理世界到人的精神世界，概莫如是。既然软件是虚拟人，它也应该拥有自己的寿命，自己的生命周期。
人的工作就是在自己的生命周期内完成自己人生的任务，这些任务有重要的有不重要的，有关乎生存必须的，有影响生活质量的，人在一生中有各种各样的需求，这些需求就构成了人的一生在不同场景、不同阶段当中不同的事务。
这些事务本身又会形成自己的生命周期。于是从概念上人一生的生命周期被各种不同的场景、任务、角色、身份切分成了各不相同的生命周期，其中有核心生命周期，有非核心生命周期，有些必须自己做，有些可以交给别人做。
在人类历史中，随着工作越来越复杂、工作任务越来越多，人类协作越来越精细，然后就产生了分工，分工就是人类因为协作产生的生命周期的切分。这样具体到每一个人都可以做自己擅长的事，从而产生剩余，然后互相交换满足各自的需求。人类分工协作的历史就是生命周期切分的历史。在软件这个虚拟世界也是如此，软件是现实世界到虚拟世界的映射与抽象，软件的运行也是由代码构成的虚拟人之间分工协作的过程。既然有分工和协作，就要明确各自的职责和权力，确保每个虚拟人之间的权责对等。
要做到虚拟人之间权责对等首先要保证现实世界的组织架构权责对等，只有做到这样才能完成从现实到虚拟的映射，不知大家在工作和生活中遇到过多少权责不对等，甚至有责无权的现象。
这种权责不对等势必难以完成从现实到虚拟的映射，相关的开发工作必然相当痛苦。因此架构一词必然不止是针对技术领域的术语，而是概括现实世界的人、事、物、权、责之间的关系以及人与人之间的分工与协作。在任何事物的发展过程中，总是伴随着生命周期的切分与合并。书中举过一个例子是人的免疫系统。免疫系统是维持人的生命必不可少的一部分，但是有一部分人由于先天或后天原因，他们的免疫系统不能正常履行免疫系统的职责，在有相应药物出现之前他们无法生存太久。
现在已经有了免疫药物，可以代替部分免疫系统的职能，延长了他们的寿命。将来可能会出现能够完全代替免疫系统的纳米机器人，由这些外来物代为行使免疫职能。
这种情况其实就是人的生存这一核心生命周期的切分。从免疫系统作为人生命的核心生命周期不可分割的一部分，到从核心生命周期分离出去。
软件开发工作也有这样的例子，从这个行业刚开始需求、建模、开发、测试、运维全都是软件工程师的事，到后来这些工作都由专门的人在做。
现在软件工程的发展又出现了开发、测试、运维职责回归到软件工程师这一角色的现象。软件工程已经经历了各生命周期从切分到合并的一个周期。明确了生命周期这个概念就会意识到，随着事物的发展，把它的一部分职能从其核心生命周期切分出去，构造出新的生命周期，能够帮助这一事物明确自身的核心生命周期、明确自己的职责和权力，有更多时间用在自己擅长的事情上。
同时伴随着新的组织架构和软件架构。新的组织架构必然伴随着新的利益调整和对利益相关人的影响，所以现实世界的组织架构往往更难变化，越成熟越稳定的组织越是如此，因为这些变化会动一些人的奶酪，而现实世界的组织架构又会影响虚拟世界的软件架构。
如果现实世界的组织架构不动，却试图改变软件架构去适应现实世界的状况必然造成虚拟人的权责不对等和虚拟人与现实世界的抽象不一致的现象。良好的架构，高效的执行力必然要有明确对等的权责划分。划分出了相应的职责，必然伴随着相应权力的拆分和下放。现实世界的组织架构是分层级的，也是树状的，甚至现实世界的一切事物都有这样的关系。动物胚胎发育过程也是一个逐渐分层、划分权责的过程。生物界的进化关系也是一个树状结构。整个宇宙也是一个树状关系。映射到虚拟世界的软件架构也要是分层级的，也是树状的结构。
从对不同职责的拆分和相似权责的合并当中，发现新的生命周期，创建新的实体。不断迭代这个过程，逐渐明确各实体的权责，并从中发现高效低成本的，淘汰低效高成本的。这就是软件的迭代过程，也是架构演化过程。软件架构必然伴随着设计、演化、变更、取舍。
明白了这一点，自然就能分得清楚访问代码、业务代码、存储代码、胶水代码各自应在哪些层级，它们应该是什么角色，而不是所有代码散乱的混在一起，看起来似乎按照经典的MVC分层，实际上业务代码却同时出现在controller/service/DAO，这样其实并没有明确的划分。
正确的做法应该是controller完成访问逻辑；DAO完成存储逻辑；service完成胶水逻辑，承上启下，利用DTO转换访问参数、执行业务逻辑、调用DAO映射存储模型、再利用DTO把业务处理结果转换为响应结果，业务逻辑在业务模型中实现。
如果把业务逻辑跟业务数据在一起实现就是充血模型，进一步深化就是DDD模式。只有这样才完成了明确的软件层次划分，每层各司其职、权责对等，否则就是大泥球。明白了这一点，自然就能分得清楚业务的事务跟关系数据库的事务不是一回事，也就不会考虑完成业务上的事务要依赖关系数据库事务确保数据完整性。
完全可以把二者分开，利用更符合业务规律的做法去实现，甚至业务本身已经有成熟的方案确保数据完整性，而不再需要依赖关系数据库事务。在业务上对关系数据库事务ACID特性的依赖既然不再是必须，对拥有ACID特性的数据库依赖自然也就不再是必须，完全可以根据业务需要选择合适的存储方案。
业务模型和具体实现不再依赖于某些具体方案的技术特性，实现了业务与技术的解耦，也就更容易实现横向扩展。现在又发现横向扩展也是自然界的一个基本特性。无数基本粒子构成原子、无数原子构成一个具体的宏观物体，一个人不够用就增加更多人。如果一个系统的规模在横向扩展上达到了瓶颈，不能再靠简单的增加数量获得提升的时候，一定是这个系统的组织架构存在某些不合理因素。说到这里自然就要说到业务和技术的关系。前面说到软件是现实世界的映射抽象，由虚拟人代替自然人去完成一些工作。要做好软件自然就要理解业务，对业务的理解越深刻就越有可能做出优秀的软件。
架构师在这个过程中就是连接从现实世界的业务到虚拟世界的软件的桥梁，做的工作是把从现实世界执行业务的自然人映射到软件世界的虚拟人。架构师自然就要深刻理解业务、深刻理解技术。为业务建造合适的模型，为模型选择合适的技术，最后才是具体的实现。
但是现实世界太复杂了，随着业务发展，软件规模会越来越大，复杂性越来越高，一个人难以胜任全部架构工作，于是就产生了架构师团队，架构师也有了更细致的分工。架构师的生命周期也相应发生了拆分，也就产生了业务架构、应用架构、系统架构。
架构师为了能够实现自己的架构思想，自然需要与职能对等的权力。所以架构师其实不是一个纯粹的技术职位，而是拥有管理职能的职位，而不同角色的架构师对技术的要求也不尽相同。《聊聊架构》使我对软件工程、架构、业务、技术产生了新的理解，也使我对人、事、物、权、责之间的关系产生了新的理解，或者这些理解正在随着我多年从业经历逐渐产生，而本书给我临门一脚，终于开悟。我认为本书特别适合刚入门软件工程或者正在软件工程门前徘徊的人阅读。也适合从业多年，仍被许多软件工程、架构思想等问题困扰的人阅读。另外我认为也很值得产品经理一读，可以帮助产品经理理解一些软件工程思想，减少与技术团队的沟通障碍。
不过如果你仍未入门软件工程，尚未有任何开发经验，我认为并不适合阅读本书，可能会让人更加迷惑。如果你对软件工程、架构思想已经有深刻理解，并自如运用多年，也不适合阅读本书，否则会像本文开头提到的那人一样，认为本书空洞无物。PS. 我在微信朋友圈多次推荐本书之后，郭蕾邀请我撰文推荐本书。刚开始我是拒绝的，因为本人对自己的写作水平实在没有自信，生怕因行文太差而不能说明自己阅读本书的感受与收获。感谢郭蕾的鼓励，我完成了自己第一篇书评，也是我对本书内容的总结和自己从业多年的总结。