第十六章 大型结构

简介

• 在一个大的系统中，如果因为缺少一种全局性的原则而使人们无法根据元素在模式（这些模式被应用于整个设计）中的角色来解释这些元素，那么开发人员会陷入“之间树木，不见森林”的境地。我们需要理解各个部分在整体中的角色，而不必去深究细节。
• 设计一种应用于整个系统的规则（或角色和关系）模式，使人们可以去通过它在一定程度上了解各个部分在整体中所处的位置（即使是在不知道各个部分的详细职责的情况下）
• 大部分大型结构都无法也不必要用UML来表示。这些大型结构是用来勾画和解释模型及设计的，但在设计中并不出现，它们只是用来表达设计的另外一种方式。
• 团队规模小模型不复杂时，只需将模型分解为合理命名的MODULE，进行一定程度的精炼，然后在开发人员中进行非正式的协调，就可以使模型保持良好的组织结构了。

一、模式：EVOLVING ORDER（有序演化）

• why？一个没有任何规则的随意设计会产生一些无法理解整体含义而且难以维护的系统。但架构中早期的假设又会使项目变得束手束脚，而且会极大限制应用程序中某些特定部分的开发人员的能力。问题不是在指导规则本身应不应该存在，而在于这些规则的来源和严格性。
• how？让这种概念上的大型结构随着应用程序一起演变，甚至可以变成一种完全不同的架构风格。不要依次过分限制详细的设计和模型决策，这些决策和模型决策必须在掌握了详细知识后才能确定。当发现了一种大型结构可以明显使系统变得清晰，而又没有对模型开发施加一些不自然的约束时，就应该采用这种结构。

二、模式：SYSTEM METAPHOR（系统隐喻）

• why？软件设计往往非常抽象而且难以掌握。开发人员和用户都需要一切可实行的方式来理解系统，并共享系统的一个整体视图。比如“防火墙”这个隐喻大家都明白是做什么的。隐喻可以传达整个设计的主题，并能够在团队所有成员中形成共同理解。
• what？系统隐喻是一种松散的、；易于理解的大型结构，它与对象范式是协调的。是对领域的一种类比。
• how？当系统的一个具体类比正好符合团队成员对系统的想象，并且能够引导他们向着一个有用的方向思考时，就应该把这个类比用作一种大型结构。围绕这个隐喻来组织设计，并吸收到UBIQUITOUS LANGUAE中。隐喻应该既能够促进系统的交流又能够指导系统的开发。

三、模式：RESPONSIBILITY LAYER（责任层）

• why？如果每个对象的职责都是人为分配的，将没有统一的指导原则和一致性，也无法把领域作为一个整体来处理。为了保持大模型的一致，有必要将在职责分配上实行一定的结构化控制。
• how？注意观察模型中概念依赖性，以及领域中不同部分的变化频率和变化原因。如果在领域中发现了自然的层次结构，就把他们转化为宽泛的抽象职责。这些职责应该描述系统的高层目的和设计。对模型进行重构，使得每个领域对象、聚合根和模型的职责都清晰的定位于一个职责层当中。
• 常见的职责层：1、潜能层，我们能够做什么；2、作业层，我们正在做什么？我们利用这些潜能做了什么事情？3、决策支持层，应该采取什么行动或制定什么策略。4、策略层，规则和目标是什么。

四、模式：KNOWLEDGE LEVEL

• 简介：知识级别是一组描述了另一组对象该有哪些行为的对象。当我们需要让用户对模型的一部分有所控制，而模型又必须满足更大的一组规则时，可以利用知识级别来处理这种情况。它可以使软件具有可配置的行为，其中实体中的角色和关系必须在安装时进行修改。
• why？如果在一个应用程序中，NETITY的角色和它们之间的关系在不同情况下有很大变化，那么复杂性将会显著增加。为了兼顾各种不同情形，对象需要引用其它类型，或者需要具备一些在不同情况下包括不同使用范式的属性。具有相同数据和行为的类可能会大量增加，而这些类的唯一作用只是为了满足不同的组装规则。
• how？创建一组不同的对象，用它们来约束基本模型的结构和行为。把这些对象分为两个级别，一个是非常具体的级别，另一个级别则提供了一些可供用户或超级用户定制的规则和知识。
• 例如超级用户的权限很大可以做一些普通用户无法做的事，这就就是一种知识。

五、模式：PLUGGABLE COMPONENT FRAMEWORK（可插入式组件框架）

• why？当很多应用程序需要进行互操作时，如果所有应用程序都基于相同的一些抽象，但它们是独立设计的，那么在多个BOUNDED CONTEXT之间的转换会限制它们的集成。各个团队之间如果不能紧密合作，就无法形成一个SHARED KERNEL。重复和分裂将会增加开发和安装的成本，而且互操作会变得难以实现。
• 一些成功的项目将他们的设计分解为组件，每个组件负责提供某些类别的功能。通常所有组件都插入到一个hub中，这个hub支持组件所需的所有协议，
• how？从接口和交互中提炼出一个ABSTRACT CORE，并创建一个框架，这个框架允许这些接口的各种不同实现被自由替换。同样，无论什么应用程序，只要它严格地通过ABSTRACT CORE的接口进行操作，那么就可以允许它使用这些组件。

七、通过重构得到更适当的结构

• 最小化，控制成本的一个关键是保持一种简单、轻量级的结构。不要试图使结构面面俱到。只需要解决最主要的问题即可，其它问题可以留到后面一个一个地解决。
• 沟通和自律，整个团队在新的开发和重构中必须遵守结构。整个团队必须理解这种结构。必须把术语和关系纳入到UBIQUITOUS LANGUAGE中。
• 通过重构得到柔性设计。
• 通过精炼可以减轻负担。