三、架构的开发成本以及品质问题解决讨论

    架构一个重大关注点在于控制开发成本，这点很重要，因为通常讲维护成本是开发成本的3倍。降低开发成本核心，在于提高效率，这也意味着提高了开发对需求的响应时间，而时间对公司来说是重要的。

    提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解对应的集成，只有提供了好的集成能力，分解才成为现实，而只有分解了，才能清晰的提供业务更多适应性。

    分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架，而框架就是弱语言。

    现代面向对象的语言提供如下能力：抽象和派生能力，以及接口隔离能力。实际提供两种分解和集成能力：

    1. 把逻辑分解在两个层次中，而通过继承的方式把两个部分集成在一起。

    2. 把逻辑的外观和实现分解在两个地方，而通过接口实现的方式把两部分集成在一起。

    另一种语言AspectJ或者C#语言2.0之后提供的特性：把流程逻辑，分解在不同的地方，而通过签名匹配，利用代码生成的方式来把几部分集成在一起。

    然而语言提供的集成能力，毕竟底层，而且有限，扩展起来也格外小心。因而技术框架提供另外的集成能力就格外重要：

    1. 对象关联关系的分解和集成，如Spring提供容器管理能力

    2. 模块间关联关系的分解和集成，如OSGi，ESB等

    3. 不同系统的类型分解和集成，如Spring利用动态代理提供的Exporter模式。

    4. 流程逻辑的分解和集成，如Spring Web Flow以及jBPM。

    讨论完手段，现在要转身看看我们面临的问题域了；问题域可分解为两种类型，业务上和技术上。（又见分解，分而治之真是老祖宗传下的灵丹妙药啊）

    1. 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。

    2. 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。

    所以通常而言，领域模型设计中，模块分解，抽象分层和职责分层都是重要手段。问题域为：流程，业务实体和计算（包括规则）。

    对象的抽象分解和集成

    对象的依赖分解和集成（模块内和模块外）

    流程的分解和集成（页面流，工作流以及计算流程）

    进程边界：用户请求重定向，以及业务数据持久化等。

    BTW：通常语言做为架构的基础引入和更换是有巨大风险的；而通过提供强大的框架能力，框架尽可能多的完成技术问题，并通过元数据，模式以及约定降低业务和框架的耦合。避免因为框架升级带来不必要的成本。

    从技术手段上，提高开发效率的另外两个手段是代码生成和类库引用。但代码生成和类库引用，都只解决了逻辑的分解能力，没有提供集成能力，所以一般情况下需要提供框架集成，尤其代码生成需要在系统的最外层，避免集成带来的问题。

    对于开发团队来说，额外面临一个问题，组织内部的学习成本问题。

    1. 需要保持分解以及集成能力本身的简约性

    这个……其实是一个culture问题，不再罗唆！

    2. 采用模式和约定是减少学习成本的另一种手段。ROR的兴起就是最好的例证。

    总结一下，解决架构面临开发成本问题需要如下几个方面：

    0. 问题域

    1. 分解与分层

    2. 架构与类库，Spring，Hibernate。起支撑性作用。

    3. 模式和技巧

    4. 领域模型

    5. 方法论

    5.1.开发方法：OO（设计模式），FP(函数式编程)。

    5.2.设计方法：Domain Model Prototype和业务行为的分析模式。

    架构面临的品质问题，则通过自动化测试，代码检测工具来完成。

    必须大量应用自动化测试，减少人工硬调试的复杂性，重复性和不确定性。

    自动化测试包括单元测试和集成测试。无论是单元测试还是集成测试对面临需要脱离隔离依赖关系并保证开发的并行性。