确定关键功能的四条启发规则

所谓对软件架构关键的功能需求，指的是它涉及（串起）的模块最多、协作方式最有代表性的功能需求——任何功能需求都是由一条特定的”模块协作链”完成的，控制权在协作链中来回传递，功能需求就相当于串起不同模块的线索；由于功能需求数量众多，很多功能需求所涉及的模块协作链其实高度相似，架构师通过分析少数关键功能需求，往往就能完成一般性的模块划分、职责分配、协作机制定义等和功能相关的核心架构设计工作。确定关键功能子集有四条启发规则。核心功能：识别标志是业务层的接口要反映这些功能，比如项目管理系统中”项目信息查看”“添加项目任务”都是核心功能。必做功能：主要依据客户方的背景来判断，技巧是回头看《愿景与范围文档》——文档”项目愿景的解决方案”中”主要特征”往往应作为必做功能的备选项，另外对业务系统而言，一般支持”运营”的功能比支持”管理”的功能优先级更高。高风险功能：出于务实考虑纳入的一类，比如网上书店系统的”全库搜索”功能——从用户角度看极慢的搜索速度令人不满，从架构设计角度看这个功能对数据库是”面状、只读”式的使用，和增加/修改书籍这类”点状、写入”式使用的特点完全不同，尽早把这类功能选入高风险功能之列，有利于针对性地做架构设计。独特功能：最后检查是否还有前三类没有涉及的职责，比如输入法软件的”词库在线更新”功能，忽略它就很难发现架构中负责和服务器交互的”互操作模块”，这类功能是相对前三类而言的补充。这四条规则共同的作用是把”关键功能”从一个模糊的直觉判断，转化成了四个具体可检验的问题：这个功能是不是业务层接口反映的核心？是不是愿景文档里明确的主要特征？是不是有特殊数据库访问模式的高风险点？是不是暴露了前三类都没触及的架构职责？