第十一章 系统
“复杂要人命,它消磨开发者的生命，让产品难以规划、构建和测试。”
--RayOzzie，微软公司首席技术官
11.1 如何建造一个城市
每个城市都有一组组人管理不同的部分，有些人负责全局，其他人负责细节。
城市能运转，还因为它演化出恰当的抽象等级和模块，好让个人和他们所管理的“组件”即便在不了解全局时也能有效地运转。
11.2 将系统的构造与使用分开
软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应
用对象，也会存在互相缠结的依赖关系。
下例就是典型的情形：延迟初始化/赋值
public Service getService(){
if(service==null)
service = new MyServiceImpl(...); // Good enoughdefault for most cases?
return service;
}应当将这个过程从正常的运行时逻辑中分离出来，确保拥有解决主要依赖问题的全局性一贯策略。
11.2.1 分解main
将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中，设计系统的其余部分时，假设所有对象都已正确构造和设置。
11.2.2 工厂
有时应用程序也要负责确定何时创建对象。
比如，在某个订单处理系统中，应用程序必须创建LineItem实体，添加到Order对象。在这种情况下，我们可以使用抽象工厂模式让应用自行控制何时创建LineItems，但构造的细节却隔离于应用程序代码之外。
11.2.3 依赖注入
有一种强大的机制可以实现分离构造与使用，那就是依赖注入（Dependency Injection，DI），控制反转（Inversion of Control，IoC）在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵盾了单一权责原则。
在依赖管理情景中，对象不应负责实体化对自身的依赖。反之，它应当将这份权责移交给其他"有权力"的机制，从而实现控制的反转。因为初始设置是一种全局问题题，这种授权机制通常要么是main例程，要么是有特定目的的容器。
11.3 扩容
“一开始就做对系统”纯属神话。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、重构以及它们打造出的整洁代码，在代码层面保证了这个过程的实现。
软件系统与物理系统可以类比。它们的架构都可以递增式地增长，只要我们持续将关注面恰当地切分。
横贯式关注面
AOP是一种恢复横贯式关注面模块化的普适手段。
在AOP中，被称为方面（aspect）的模块构造指明了系统中哪些点的行为会以某种方式被修改，从而支持某种特定的场景。这种说明是用某种简洁的声明或编程机制来实现的一致的。
11.4 Java代理
Java代理适用于简单的情况，例如在单独的对象或类中包装方法调用。然而，JDK提供的动态代理仅能与接口协同工作。对于代理类，你得使用字节码操作库，比如CGLIB、ASM或Javassist。
11.5 纯 Java AOP 框架
幸运的是，编程工具能自动处理大多数代理模板代码。在数个Java相架中，代理都是内嵌的，如SpringAOP和JBossAOP等，从而能够以纯Java代码实现面向方面编程。在Spring中，你将业务逻辑编码为旧式Java对象。POJO自扫门前雪，并不依赖于企业框架（或其他域）。因此，它在概念上更简单、更易于测试驱动。相对简单性也较易于保证正确地实现相应的用户故事，并为未来的用户故事维护和改进代码。
使用描述性配置文件或API，你把需要的应用程序构架组合起来，包括持久化、事务、安全、缓存、恢复等横贯性问题。在许多情况下，你实际上只是指定Spring或Jboss类库，框架以对用户透明的方式处理使用Java代理或字节代码库的机制。这些声明驱动了依赖注入（DI）容器，DI容器再实体化主要对象，并按需将对象连接起来。
11.6 AspectJ 的方面
通过方面来实现关注面切分的功能最全的工具是AspectJ语言，一种提供“一流的”将方面作为模块构造处理支持的Java扩展。在80%~90%用到方面特性的情况下，SpringAOP和JBossAOP提供的纯Java实现手段足够使用。然而，AspectJ却提供了一套用以切分关注面的丰富而强有力的工具。AspectJ的弱势在于，需要采用几种新工具，学习新语言构造和使用方式。
藉由AspectJ近期引入的“annotation form”（使用Java5annotation定义纯Java代码的方面），新工具采用的问题大大减少。另外，Spring Framework 也有一些让拥有较少 AspectJ 经验的团队更容易组合基于annotation的方面的特性。
11.7 测试驱动系统架构
最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java（或其他语言）对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来，这种架构能测试驱动，就像代码一样。
11.8 优化决策
模块化和关注面切分成就了分散化管理和决策。在巨大的系统中，不管是一座城市或一个软件项目，无人能做所有决策。众所周知，最好是授权给最有资格的人。但我们常常忘记了，延迟决策至最后一刻也是好手段。
拥有模块化关注面的POJO系统提供的敏捷能力，允许我们基于最新的知识做出优化的、时机刚好的决策，决策的复杂性也降低了。
11.9 明智使用添加了可论证价值的标准
有了标准，就更易复用想法和组件、雇用拥有相关经验的人才、封装好点子，以及将组件连接起来。不过，创立标准的过程有时却漫长到行业等不及的程度，有些标准没能与它要服务的采用者的真实需求相结合。
11.10 系统需要领域特定语言
领域特定语言（Domain-SpecificLanguage，DSL）是一种单独的小型脚本语言或以标准语言写就的API，领域专家可以用它编写读起来像是组织严谨的散文一般的代码。
DSL在有效使用时能提升代码惯用法和设计模式之上的抽象层次。它允许开发者在恰当的抽象层级上直指代码的初衷。
领域特定语言允许所有抽象层级和应用程序中的所有领域，从高级策略到底层细节，使用POJO来表达。
11.11 小结
系统也应该是整洁的。侵害性架构会湮灭领域逻辑，冲击敏捷能力。当领域逻辑受到困扰，质量也就堪忧，因为缺陷更易隐藏，用户故事更难实现。当敏捷能力受到损害时，生产力也会降低，TDD的好处遗失殆尽。
在所有的抽象层级上，意图都应该清晰可辨。只有在编写POJO并使用类方面的机制来无损地组合其他关注面时，这种事情才会发生。
无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。
