写架构设计文档有感
写架构设计文档有感
Anatta前段时间写了篇架构设计文档，一直想就这件事聊点什么，结果一拖就拖到现在了。算起来这是我第二次写架构设计文档了。一路摸爬滚打，算是有一点点领悟，也不知道对不对，就随便说说。
很多人觉得架构文档没有什么写的，或者说不知道要怎么写。其实我觉得这是因为自己对架构、或者对业务需求并不是那么理解。如果真的理解了，再来写这个文档，会发现真的有很多可以写的地方。因为你在明白架构设计文档的目的、作用后，就知道这个东西不仅仅是拿来糊弄公司的，而是真的有指导意义的。
首先要理解架构设计文档的作用，架构设计文档其实对项目开发是有很大帮助的，而且在写架构设计文档的过程中，也能让设计师认真的重新梳理一遍业务需求，从而有针对性的去设计，而不是在写代码过程中临时决定要用什么方法去写。
突然想起之前面试的时候问面试者，架构是什么？ 听到的回答五花八门，什么都有。有的人干脆就说架构就是 MVC，MVP 等等，让人有点无奈。我在这里简单聊一下我的理解。
什么是架构？
架构这个词其实并不是软件领域专有的。它甚至可以追溯到人类起源的时候。
刚开始人类只有很简单的需求：有东西吃、有地方睡。一个人就能做完所有的事情。但是随着需求变得多样性，还有技术领域的细分化，一个人做不完所有的事情了，而且也学不会那么多技能。这个时候社会分工就出现了。随即演变出了社会组织架构。包括现在的企业组织架构，都是为了更好的分工而生的。
建筑中的架构也是类似的。一开始就一个茅草屋，一个火坑，简简单单的屋子就够了，不需要什么架构设计。随着社会的发展，人们对建筑功能的需求也越来越多，空间的切分也越来越细致。以居所为例，出现了客厅、餐厅、厨房、卧室、卫生间等专用空间。随着人们对空间划分变得细致、空间组合变得多样，建筑架构就应运而生了。
那么在软件领域，架构最根本的目的，我认为也是为了让一个团队能更好的分工，进而更好的合作。
之前说了，写不出文档一方面是因为对架构理解不到位。另一方面就是因为对业务需求理解的不到位，那么为什么业务需求对架构这么重要呢？
什么是业务需求？
业务在很大的程度上决定了一个团队的分工。但是在讲业务需求之前，我想先聊一下程序员所需要解决的两类问题。
第一类就是生意问题。我们制作的软件，其实都是为了做生意。而且很多时候，这个生意没有了软件一样能做，只是比较低效而已。我们只是生产了一个工具，可以提升做生意的效率。
另一类问题，就是计算机问题，是用来支撑我们去生产这个工具的，比如计算机、数据库、网络等等，都是为了更好的支撑我们去模拟做生意的过程。
这两类问题，都会对我们的架构设计产生或深或远的影响，所以一定要在设计前就有一定的了解。
接下来聊聊业务需求为什么会对架构设计产生深远的影响。我们先看一下建筑的用途是怎么影响到建筑的架构的。
像农村里的普通住宅（一般规模），砖混结构就够用了；城镇的中低层住宅楼（规模变大），就需要框架结构；高层住宅（规模进一步变大）的结构也不一样，是核心筒 + 剪力墙；至于像机场、车站这种需要超大空间的建筑体（另一种使用场景），则又需要大跨结构。你看，建筑上不同的空间诉求，对架构的要求也是不同的。
回到软件领域，不同的业务，它的特点也不一样。像活动这种，天天在变，那么架构设计上就需要考虑快速迭代和快速开发；像日志系统，每天都有大量写入，但是读取比较少，所以在设计的时候也要考虑性能和稳定性等因素。不同的业务需求，有不同的特性，我们要在架构设计的时候就考虑进去这些特性，并且尽力去满足这些需求。
在这里我再多嘴一句，很多时候我们接收到的任务，其实是别人给过来一个解决方案，并不是他想解决的问题。我们要学会识别这个陷阱，因为别人给的解决方案可能并不是最优的解决方案，甚至可能是错的。我们需要直面问题，然后解决问题，这样是最高效的。
怎么写架构设计文档
说了这么多，到底要怎么写架构设计文档呢？
我觉得架构文档最应该体现的就是：对业务需求的合理分解，以及对各个子业务的特性的理解。对业务进行了合理的分解后，我们的项目就有了一个比较合理的骨架，这个骨架就是我们的底层架构。然后再对每个子模块做概要设计，随后将底层架构和上层的各个子模块的设计进行融合。其实这个过程就是一个化繁为简的过程，将繁琐的业务转化为一个个关键类和协议接口。
到了这一步，我们对业务已经有了很明确的认知了，自然也清楚每个模块的特性，此时再做技术选型，就有很强的目的性了。这样一来计算机问题也就随着业务问题一起解决了。
这里有一个文档纲领，只要思路正确，直接填鸭也没啥问题。
1 | 一、概述 |
