1.1 Domain Model

      创建一个模型来定义系统的业务职责及其变化范畴，模型元素是对应用领域的有用抽象，其角色和交互反映了该领域的工作流。

      我们可以通过适当的方法来创建Domain Model，比如领域驱动设计和领域分析，还有一些专门表现领域变化的方法，如普遍性/多样性分析和特性建模等。领域相关的模式能进一步支持Domain Model的创建，它们可以提供该领域中公共抽象和工作重复采用的经典解决方案，包括这些解决方案可能的相应变体。

 

1.2 Layers

      不管软件系统不同部分之间有什么样的交互和耦合，我们都希望能对其进行独立的开发和改进，这可能跟系统的大小有关或者是上市时间方面的要求。然而，如果对系统软件架构的不同方面没有一个清晰合理的划分，就很难支持各部分之间的合理交互，进而也无法独立开发。

      因此，要为待开发系统定义多个Layers，每一层都有明确而具体的职责。

      Layers架构根据（子）系统级属性定义了软件功能的横向划分，从而将每组功能都清晰封装起来以便独立改进。具体的划分标准可以通过各种不同的维度来定义，如抽象性、粒度、硬件距离以及变化率。例如，将架构划分为表现层，应用逻辑层和持久化数据层的分层方法是从抽象性维度来划分的；引入业务对象层，其内部实体单元供业务处理层使用，这种分层机制是按粒度来划分；而将系统分为操作系统抽象层，通信协议层和应用功能层的分层机制是按照硬件距离来划分的；采用变化率作为分层标准使得划分后的功能能彼此独立地升级。实现应用中会结合使用多种维度。

      Layers的关键问题是确定“合适”的层数。层数太少可能无法将系统中的不同问题充分地分离开以便独立升级。相反，层数太多又容易导致软件架构过于零碎而没有清晰的视图和范畴，从而非常难以改进。此外，定义的层数越多，端到端的控制需要穿越的中间层就越多，可能会引入性能问题——特别是在层与层之间是远程的时候。

 

1.3 Model - View - Controller

      用户界面总倾向于发生变化，有些必须支持多种外观体验，另一些必须满足特定顾客的偏好。然而，更改用户界面必须不影响应用的核心功能，这部分通常是独立于外观的，变化也较少。

      因此：将交互式应用划分为3个独立部分：处理、输入和输出。采用变化传播机制来确保这3部分的一致性。

      将应用的功能核心封装到Model中，其实现独立于具体的用户界面视感和机制。当Model中的某个方面需要通过应用的用户界面展示出来时，为其引入一个或多个自我完备的View，将各View和一系列独立的Controller关联起来，以接收用户输入并将其转换成对Model或相关View的请求。这样，用户就可以只通过Controller和应用交互。

      将Model，View和Controller组件通过变化传播机制连接起来，当Model的状态发生变化，通知所有View和Controller做相应的改变，以便它们能通过Model的API完成对自身状态及时准确的更新。

      Model - View - Controller的实现方式将不同变化率的应用职责分离开，从而支持它们独立地改进。

 

1.4 Presentation - Abstraction - Control

      人-机界面允许用户通过特定“方式”与应用交互，如窗体、菜单、对话框等。不过，某些应用最好通过不同的界面形式来操作其所提供的不同功能类型。 

      因此，将交互式应用结构化，使其形成由多个解耦的代理构成的层次：一个顶层代理，几个中间层代理和许多底层代理。每个代理负责应用的一个特定功能并为其提供特定用户界面。

      底层代理实现了用户可与之交互的自我完备功能，如管理性任务、出错处理和数据操作。中间层代理协调多个相关的底层代理，例如用于呈现特定数据类型的所有View。顶层代理提供所有代理共享的核心功能，如访问数据库。

      Presentation - Abstraction - Control架构有助于连接多个自我完备的子系统，甚至是连接整个应用，通过专门的人-机交互Model构成内聚的（分布式）系统。这种方式的不足之处在于其复杂性：必须提供多个用户界面，而且当控制流分散在多个子系统中，当需要在相关的用户界面中做出反应或更新View时，必须对某个用户界面触发的行为进行仔细明确地协调。因此，Presentation - Abstraction - Control架构只有在软件系统不采用单一用户界面模式实现时才有实用价值。

 

1.5 Microkernel

      有些应用存在多个版本。每个版本向用户提供不同的功能集，或者是和其他版本在特定方面有所不同，比如用户界面。尽管它们存在差异，应用的所有版本都应当基于一个公共的架构和功能核心。

      因此，通过“即插即用”机制来扩展一个公共且最小的内核来为应用构造不同的版本。

      Microkernel实现应用的所有版本共享的功能，并为集成某个版本特有的功能提供基础设施。内部服务器实现自我完备的特定版本的功能。外部服务器实现特定版本的用户界面或API。要配置应用的特定版本，我们只需要将相应的内部服务器和Microkernel连接起来，并提供合适的外部服务器来访问其功能。因此，应用的所有版本共享一个公共的功能和基础设施内核，但却可以提供不同的功能集和外观体验。

      Microkernel架构确保应用的每个版本可以完全按照其目的进行裁剪。用户或客户端系统只得到其要求的功能和外观体验，而不会为他们所不需要的特性引入任何开销。一般来说，改进某一特定版本以包含新的或不同功能和特性，“只”需要重新配置合适的内部和外部服务器，Microkernel自身不受这种升级的影响，已存在的内部和外部服务器以及应用的其他版本同样不受影响。此外，Microkernel架构降低了开发和维护整个应用系统中所有成员的成本，每个服务，用户界面和API只需要实现一次。