最近帮公司开发OA系统，由于是项目经理，所以参与了系统的架构设计。偶有感想，便付于纸面。
有何不妥之处还望各位指点。
第一：需求分析一定要仔细，越明确用户的需要越可能较好的把握架构的设计，因为需求确定软件架构。
第二：要从用户角度考虑各种与软件和软件架构有关的因素,这些因素是：
1）架构的简单性，这和设计机器设备时要保证结构简单（从而可以使用户简单维护，用户不懂机器设计！！）的原理是一致的。但是这也带来了简单复杂性，为何？打个比方：现代的pc体积很小，但结构上和第一台计算机大致一致，然而现在一般人都可以使用PC，而第一台计算机却要专业不能再专业的人使用。之所以现在人们可以轻松使用PC，是因为交互界面和硬件维护简单了。软件的架构也是这个道理，虽然看起来我们把它设计很简单，很容易维护，但开发人员不知道要为它多封装几层的功能代码！对用户而言简单了，对开发人员复杂了，但软件最终是给用户使用的，所以简单就是真理。这就是所谓的“有得必有失吧”。
2）适度性：有的开发人员愿意搞“完美主义”，什么都要最全最好，但是用户只需要那么点功能，而且用户只给你那么多时间和资源。然而有些开发人员将时间和金钱用在了用户不需要的功能上（国内的开发人员容易这样作），带来了项目的进度和成本的风险。很不划算！所以设计架构时我注意了必要的功能我一定集中精力设计，对于没有必要的我会考虑舍去。
3）适应性：用户的业务总在变化，所以要使用灵活的架构！设计模式将是一个较好的解决方法。
4）高内聚低耦合：这是老声长谈的问题，然而又有多少人做的好哪？
5）开发不能一步到位：人的思维模式总是从简单到复杂，然而有有些开发人员喜欢一步到位，上来就编代码！这样很会造成后期不断修改的结果，所以软件开发要从简单到复杂，不求一步到位。
6）要善用辅助工具：有的开发人员认为软件重用就是开发一个组件就可以了，但是方法重用哪？很多好的软件设计、开发方法被集成在如CASE,代码生成等工具中，然而很多开发人员不用，他们喜欢从零开始，但是我们开发软件目的是显示我们技术高超还是为用户及时地高质量的提供可用的软件？善用工具的人必定是善于理解用户需求的人。软件开发的目的性决定了开发人员应当有何行为，而非技术。
未完待续
具体的架构设计方法会在以后的文章中讲述。请各位指点
