又一次写架构设计文档，现在至少也是写过6、7次架构设计文档了，每次写架构设计文档自己都有感觉，每次的想法都不同，所以每次的目录结构都有所改动(尽管公司有规范，但我会按自己的理解进行重整)，应该说觉得写了这么多次以来，每次都觉得当时的那次是写的最好的，慢慢的也明白自己在写架构文档方面已经在不断的进步了，其实我认为，能不能写出架构文档很能反应出设计师是否真正的掌握了架构的设计，很多时候觉得架构设计文档没什么写的其实已经表明设计师其实对架构并不是那么的理解，在理解了后要写出来真的是一发不可收拾，都可以写很多，因为要明白架构设计文档的对象，架构文档的作用，尽管现在很多情况下架构文档都是拿来糊弄用户，但我觉得作为设计师还是应该写出一份合格的架构设计文档，架构设计文档对于整个项目的实现具有很大的指导意义，写架构设计文档能让设计师真正的仔细梳理整个系统的架构设计，不会是那种临时突然想出的东西。
这次在写架构设计文档中也开始仔细的考虑架构设计文档到底需要体现什么呢？其次需要明白到底何谓架构，其实我觉得一个形象的说法就是骨架，每个人、每栋房子都需要有骨架，基于这个骨架可实现用户的功能需求以及非功能需求，那么就可以说这是个成功的架构，我觉得在架构设计文档中最重要的是体现出对于系统需求的共性的分析，抽象形成系统的底层支撑子系统(注意，这个子系统是系统业务的共性，而不是具体的功能模块，具体的功能模块是基于此支撑子系统进行搭建的)，同时列出系统的非功能性需求，提出在架构级别的应对策略，在经过这个架构分析过程后，根据系统结构是C/S、B/S可提出一个底层架构体系，如B/S采用MVC思想搭建的架构体系，在M进行划分形成N层体系，在做出了底层架构体系设计后将之上架构分析中产生的支撑子系统与之进行融合，同时结合非功能性需求的应对策略，在这个情况下系统的架构图就产生了，^_^，经过这样的过程你系统的架构图就不会是无缘无故产生出来的，在架构图产生后此时就需要做技术的映射，因为在架构图的底层架构体系中列出来的是layer，那么每个layer其设计模型是怎么样的、每个layer的依赖是怎么解决的，在解决完了这个部分后需要对之上的支撑子系统进行设计模型、接口的描述，在完成了这些后即可绘制系统的部署视图、逻辑视图以及物理视图，重要的是需体现出整个系统的需求是如何基于这个架构体系来实现的，在完成了之上的过程后整个架构设计过程可以算是完成了大半部分，在这之后进行支撑子系统的模块划分以及系统功能模块的划分，划分原则依据功能内聚来进行，同时也需考虑架构体系的设计约束，在划分完毕后即产生了系统的模块视图，同时需标明模块的接口关系，在此图绘制完毕后按模块对模块的职责进行描述，同时对其接口做出规范，至此整个架构设计文档才算是比较完整的完成了，^_^，这样写下来我想这份架构设计文档想薄都难呀，架构设计文档作为整个系统后续的设计约束以及方向指导而存在。
这是在这次写架构设计文档后的一些感想，总体来说我觉得最重要的仍然是需要明确的知道架构设计文档的目的，何谓架构，架构设计的过程，架构对于需求的满足，在这之后可进行模块的概要设计，模块的概要设计其实同样是一个由繁化简的过程，产生出关键类以及类的接口设计，详细设计则是具体的对象设计以及接口实现。