OO系统架构设计浅谈

    我们设计系统是为子完成某项业务，为系统设计特定的模式则主要是了项目开发和后期维护，而两者中维护更是主要目标。为此，Peter Coad提出了他的三个设计目标：可扩展性，灵活性，可插入性。对于以抽象、继承和多态为主要特性的OO设计，人们又提出了三个设计原则：
    1.封装变化Encapsulate what varies.
    2.面向接口编程而非实现 Code to an interface rather than to an implementation.
    3.优先使用组合而非继承 Favor Composition Over Inheritance

    整体来讲，我觉得设计目标更倾向于架构设计的指导思想，而OO的特性和原则更接近具体编码的指导思想。

    从整体的系统设计入手，我认为设计工作主要为分横向与纵向设计两个方面。横向设计主要包括业务范围的设计，纵向设计则主要体现在业务层次的设计，说得熟悉一点也就逻辑架构也物理架构的综合设计，它包括了一个整体的业务逻辑实现过程。就设计的先后顺序而言，我更倾向于先横向再纵向，也就是先确定业务范围，再根据业务要求及业务范围确定相应的层次。
    为了达到《设计目标》，需要对业务进行分类（当然，我这里的业务指的是系统功能业务，即系统角色，如工具、逻辑控制、前端、数据库等，这些需要根据具体的客户业务进行翻译后得出），确定哪些是变化的，哪些是不变的，哪些是公用的，哪些是私有的，然后再此基础上，我们产生了业务间的逻辑架构，相应的也有了业务的接口。
    如果我们的系统包含子系统（这个在使用Maven进行系统管理的时候会经常遇到），那么一个普通的Java系统就会形成这么一个层次结构：系统->子系统->模块->包->类。
    为达到封装的要求，我们会希望在每个层次的每个单元都相互独立（高度内聚，低度耦合）。这样对于每个层次重复按照设计目标进行设计，那么我们最终可以得到一个“高度内聚，低度耦合，面向接口”的系统，而且，这个结论对于系统的每个单元都适用。
    而为了完成这个目标，关键在于每个层次的业务分析，也就是识别变化，恰当抽象，做好封装。
    而要做好抽象的接口，掌握好基本的设计模式是至关重要的。这些算是经验的总结，涵盖了日常使用的大部情况。当然，如果可以，也可以在日常设计中根据自己的设计目标形成自己的设计模式。可以说，整个设计过程其实就是对设计模式的反复迭代。