第十一章 系统
11.1 如何建造一个城市
没有人可以掌管细节。城市里会有一组组人管理着不同的部分，有些人负责全局，有些人负责细节。
软件团队也是，整洁的代码帮助我们在较低级的抽象层上达成这一目标。
本章的重点是在较高的抽象层级——系统层级——上保持整洁。
11.2 将系统的构造与使用分开
构造和使用是非常不一样的过程。就像大楼在建设的时候，起重机、挖机、工人。建成之后，这些都看不见了。只有工作、和住宿的人。
软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应用对象，也会存在互相缠结的依赖关系。
有些程序就没有做分离处理，启动过程代码被混杂到运行逻辑。
11.2.1 分解main
将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中， 设计系统的其余部分时，假设所有对象都已正确构造和设置。
11.2.2 工厂
有时应用程序也要负责确定何时创建对象。
比如在订单系统中，程序必须创建Lineltem 实体，添加到Order 对象。在这种情况下，我们可以使用抽象工厂模式让应用自行控制何时创建Lineltems ,但构造的细节却隔离于应用程序代码之外。
11.2.3 依赖注入
有一种强大的机制可以实现分离构造与使用，那就是依赖注入,控制反转在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵循了单一权责原则。在依赖管理情景中，对象不应负责实体化对自身的依赖。反之，它应当将这份权责移交给其他“有权力”的机制，从而实现控制的反转。因为初始设置是一种全局问题，这种授权机制通常要么是main例程，要么是有特定目的的容器。
11.3 扩容
城市由城镇发展而来，一开始不会有大马路，大型超市等等。如果一开始就建一条6车道的大马路，谁敢打包票说不会浪费呢？
系统设计也是如此，他的架构都可以递增性的增长，只要我们持续的将关注面恰当的切分。
11.4 java代理
Java代理适用于简单的情况，例如在单独的对象或类中包装方法调用。然而，JDK提供 的动态代理仅能与接口协同工作。对于代理类，你得使用字节码操作库，比如CGLIB 、ASM 或Javassist3。
Java对象就是实现InvocationHandler接口。
11.5 纯Java AOP框架
spring的AOP就很简洁。
11.6 Aspect的方面
AspectJ 提供了一套用以切分关注面的丰富而强有力的工具。AspectJ 的弱势在于，需要采用几种新工具，学习新语言构造和使 用方式。
11.7 测试驱动系统架构
通过方面式的手段切分关注面的威力不可低估。假使你能用POJO编写应用程序的领域 逻辑，在代码层面与架构关注面分离开，就有可能真正地用测试来驱动架构。采用一些新技术， 就能将架构按需从简单演化到精细。没必要先做大设计(Big Design Up Front,,BDUF)1。实 际上，BDUF甚至是有害的，它阻碍改进，因为心理上会抵制丢弃既成之事，也因为架构上 的方案选择影响到后续的设计思路。
最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java(或其他语言)对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来。这种架构 能测试驱动，就像代码一样。
11.8 优化决策
模块化和关注面切分成就了分散化管理和决策。在巨大的系统中，不管是一座城市或一 个软件项目，无人能做所有决策。
拥有模块化关注面的POJO系统提供的敏捷能力，允许我们基于最新的知识做出优 化的、时机刚好的决策。决策的复杂性也降低了。
11.9 明智使用添加了可论证价值的标准
有了标准，就更易复用想法和组件、雇用拥有相关经验的人才、封装好点子，以及 将组件连接起来。不过，创立标准的过程有时却漫长到行业等不及的程度，有些标准没 能与它要服务的采用者的真实需求相结合
11.10 系统需要领域特定语言
DSL在有效使用时能提升代码惯用法和设计模式之上的抽象层次。它允许开发者在恰当 的抽象层级上直指代码的初衷。
领域特定语言允许所有抽象层级和应用程序中的所有领域，从高级策略到底层细节， 使用POJO来表达
11.11 小结
系统也应该是整洁的。侵害性架构会湮灭领域逻辑，冲击敏捷能力。当领域逻辑受到困 扰，质量也就堪忧，因为缺陷更易隐藏，用户故事更难实现。当敏捷能力受到损害时，生产 力也会降低，TDD的好处遗失殆尽。
在所有的抽象层级上，意图都应该清晰可辨。只有在编写POJO并使用类方面的机制来 无损地组合其他关注面时，这种事情才会发生。
无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。
