定义与特点
外观（Facade）模式的定义：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。
- 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
- 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
- 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
外观（Facade）模式的主要缺点如下。
- 不能很好地限制客户使用子系统类。
- 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
模式的结构
外观（Facade）模式包含以下主要角色。
- 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
- 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
- 客户（Client）角色：通过一个外观角色访问各个子系统的功能。
理解外观模式
个人认为，外观模式更多的应用在了系统边界的划分上，而不是代码级别的设计，针对的是在系统层面领域能力的一种设计。以及是否对外界暴露子系统，和DDD的领域划分也是类似的。对领域外部暴露的是外观接口，领域内部的子系统之间的交互对外部是透明的。由此看来DDD也是遵循了设计原则（这里更多体现的是迪米特法则）而升华归类出来的。
之前外观模式还觉得很难理解，自从接触了DDD后，对外观模式的认识就变成了另一方面的角度了，知识就是这样的触类旁通，果然古人诚不欺我。
