识别驱动架构特征是创建架构或确定现有架构有效性的第一步。 为给定问题或应用识别正确的架构特征 ("-ilities")，要求架构师不仅了解领域问题，而且还与问题领域利益相关者合作，从领域角度确定真正重要的事情。

架构师通过从领域关注点，需求和隐式领域知识中提取出来，至少以三种方式揭示了架构特征。 前面我们讨论了隐式特性，在此介绍另外两个。

从领域关注中提取架构特征

架构师必须能够转换领域关注点，以识别正确的架构特征。例如，可伸缩性是最重要的问题，还是容错性，安全性或性能？也许系统需要将所有四个特征组合在一起。了解关键的领域目标和领域情况，可使架构师将这些领域问题转换为"-ilities"，从而为正确、合理的架构决策奠定基础。

与领域涉众合作定义驱动架构特征的一个技巧是努力使最终清单尽可能短。架构中的常见反模式需要尝试设计一种通用架构，该架构支持所有架构特征。架构支持的每种架构特征使整个系统的设计变得复杂；在架构师和开发人员甚至没有开始解决问题域（编写软件的原始动机）之前，支持太多的架构特征就导致越来越复杂。不要着迷于特征的数量，而是要保持设计简洁的动机。

许多架构师和领域涉众都希望确定应用或系统必须支持的最终架构特征的优先级。尽管这当然是合乎需要的，但在大多数情况下，这是愚蠢的事，不仅会浪费时间，而且还会导致与主要利益相关者的不必要的挫败感和分歧。所有利益相关者很少会就每个特征的优先级达成一致。更好的方法是让领域涉众从最终列表中以任何顺序选择前三个最重要的特征。这不仅容易达成共识，而且还引发了关于最重要内容的讨论，并帮助架构师在做出重要的架构决策时分析了权衡取舍。

大多数架构特征来自于聆听关键领域的利益相关者并与他们合作以确定从领域角度来看重要的事情。尽管这似乎是一项简单的活动，但问题是架构师和领域涉众使用不同的语言。架构师谈论可伸缩性、互操作性、容错性、可学习性和可用性。领域利益相关者讨论并购、用户满意度、上市时间和竞争优势。发生的是“翻译丢失”问题，在该问题中，架构师和领域利益相关者彼此不了解。架构师不知道如何创建一种架构来支持用户满意度，并且领域利益相关者也不了解为什么如此集中精力，而谈论应用的可用性、互操作性、可学习性和容错性。幸运的是，通常可以将领域关注转换为架构特征。下表显示了一些更常见的域问题以及支持它们的相应"-ilities"。

表——将领域关注点转换为架构特征

需要注意的重要一件事是敏捷性不等于上市时间。相反，它是敏捷性+可测试性+可部署性。这是许多架构师在翻译领域问题时会陷入的陷阱。只关注其中一种成分就像忘记将面粉放入面糊中一样。例如，某个领域的利益相关者可能会说“由于监管要求，我们必须要按时完成日末基金定价。”效率低下的架构师可能只关注性能，因为这似乎是该领域关注的重点。但是，该架构师将由于许多原因而失败。首先，如果系统在需要时不可用，则系统的速度并不重要。其次，随着领域的增长和更多资金的产生，该系统还必须能够扩展以及时完成日终处理。第三，该系统不仅必须可用，而且还必须可靠，以免在计算日末基金价格时崩溃。第四，如果日末基金定价已完成约85％，并且系统崩溃，会发生什么情况？它必须能够恢复并在价格停止的地方重新启动。最后，该系统可能很快，但是是否正确计算了基金价格？因此，除了性能之外，架构师还必须同样关注可用性、可伸缩性、可靠性、可恢复性和可审计性。

从需求中提取架构特征

一些架构特征来自需求文档中的明确声明。例如，明确的预期用户数量和规模通常会出现在域或域问题中。其他方面则来自架构师固有的领域知识，这是领域知识始终对架构师有益的众多原因之一。例如，假设一名架构师设计了一个处理大学生班级注册的应用。为了简化数学模型，假设学校有1,000名学生和10个小时的注册时间。架构师是否应该设计一个假设规模不变的系统，并隐式地假设学生在注册过程中会随着时间的推移平均分配自己？或者，基于对大学生习惯和倾向的了解​​，架构师是否应该设计一个系统来处理过去10分钟内尝试注册的所有1,000名学生？任何了解刻板刻板的学生数量的人都知道这个问题的答案！这样的细节很少会出现在需求文档中，但是它们确实可以为设计决策提供依据。

案例研究：硅谷三明治

为了说明几个概念，我们使用了体系结构Kata。为了说明架构师如何从需求中获取架构特征，我们介绍了硅谷三明治Kata。

描述
一家国家三明治店希望启用在线订购（除了其当前的呼叫服务之外）。

用户
千，也许有一天百万

需求

• 用户将下订单，然后有时间拿起三明治和前往商店的路线（商店必须与包括交通信息在内的多个外部地图服务集成）
• 如果商店提供送货服务，请向驾驶员派发三明治和三明治
• 移动设备可访问性
• 提供全国每日促销/特价
• 提供当地每日促销/特价
• 接受在线付款，亲自付款或在交货时付款

其他背景

• 三明治店专营权，每个店主拥有不同的所有者
• 母公司近期计划向海外扩张
• 公司目标是雇用廉价劳动力以最大程度地提高利润

在这种情况下，架构师将如何得出架构特征？需求的每个部分都可能对架构的一个或多个方面有所贡献（很多方面不会）。架构师不会在这里设计整个系统-仍然必须花费大量精力来编写代码来解决域声明。而是，架构师寻找影响或影响设计的事物，尤其是结构。

首先，将候选架构特征分为显式和隐式特征。

显式特征

明确的架构特征作为必需设计的一部分出现在需求规范中。例如，购物网站可能希望支持特定数量的并发用户，这是领域分析师在要求中指定的。架构师应考虑需求的每个部分，以了解其是否有助于架构特征。但是首先，架构师应该考虑关于预期指标的域级预测，如Kata的“用户”部分所述。

用户数量应引起架构师的关注，其中第一个细节是用户数量：目前有数千名用户，也许一天有数百万人（这是一家雄心勃勃的三明治店！）。因此，可伸缩性（在不严重降低性能的情况下处理大量并发用户的能力）是最重要的架构特征之一。请注意，问题说明并未明确要求可扩展性，而是将该要求表示为预期的用户数量。架构师必须经常将领域语言解码为等效的工程设计。

但是，我们可能还需要弹性—处理突发请求的能力。这两个特征通常看起来是混在一起的，但是它们有不同的约束。可扩展性看起来如图所示。

image.png

另一方面，弹性可衡量流量的爆发，如图所示。

image.png

一些系统是可伸缩的，但不是弹性的。例如，考虑一个旅馆预订系统。如果没有特殊的销售或活动，用户数量可能会保持一致。相反，考虑音乐会门票预订系统。随着新票的发售，狂热的粉丝将涌入现场，这需要高度的弹性。弹性系统通常还需要可伸缩性：处理突发事件和大量并发用户的能力。

弹性要求未出现在“硅三明治”要求中，但架构师应将其确定为重要考虑因素。需求有时会直截了当地指出架构特征，但在问题领域内却有些潜伏。考虑一个三明治店。整天的流量是否一致？还是在进餐时间忍受交通拥挤？几乎可以肯定是后者。因此，好的架构师应该确定这种潜在的架构特征。

架构师应依次考虑所有这些业务需求，以查看架构特征是否存在：

1. 用户将下订单，然后有时间拿起三明治和前往商店的路线（商店必须提供与包含交通信息的外部地图服务集成的选项）。
   外部映射服务暗示集成点，这可能会影响可靠性等方面。例如，如果开发人员构建的系统依赖于第三方系统，但是调用失败，则会影响调用系统的可靠性。但是，架构师还必须警惕过度指定的架构特征。如果外部交通服务中断了怎么办？ 硅谷三明治网站网站是否应该失败，或者在没有交通信息的情况下其效率会降低一点？建筑师应始终防止在设计中造成不必要的脆性或脆弱性。

2. 如果商店提供送货服务，请向驾驶员派发三明治。
   似乎不需要特殊的体系结构特征来支持此要求。

3. 移动设备的可访问性。
   此要求将主要影响应用程序的设计，指向构建便携式Web应用程序或几个本机Web应用程序。考虑到预算的限制和应用程序的简单性，架构师可能会认为构建多个应用过于刻薄，因此设计指向了针对移动设备进行了优化的Web应用。因此，架构师可能希望为页面加载时间和其他对移动敏感的特性定义一些特定的性能架构特性。请注意，架构师不应在这种情况下独自行动，而应与用户体验设计师，领域利益相关者以及其他有关方面合作，以审查此类决定。

4. 提供全国性的日常促销/特价。

5. 提供当地每日促销/特价。
   这两个要求都指定了促销和特价中的可定制性。请注意，需求1还隐含基于地址的自定义交通信息。基于所有这三个需求，架构师可以将可定制性视为架构特征。例如，微内核架构等架构样式通过定义插件架构，可以很好地支持自定义行为。在这种情况下，默认行为会出现在核心中，并且开发人员会根据位置通过插件编写可选的自定义部件。但是，传统设计也可以通过设计模式（例如模板方法）来满足此要求。这个难题在架构中很常见，需要架构师不断权衡各种竞争方案之间的权衡。我们将在“设计与架构和权衡”中详细讨论特定的权衡。

6. 在线，当面或交付时接受付款。
   在线支付暗含安全性，但此要求中没有任何一项表明安全性比隐含的安全性特别高。

7. 三明治店是专营店，每家店都有不同的所有者。
   此要求可能会对架构施加成本限制—架构师应检查可行性（应用诸如成本，时间和员工技能集之类的约束），以查看是否需要使用简单或牺牲性架构。

8. 母公司有近期向海外扩张的计划。
   此要求意味着国际化，即国际化。有许多设计技术可以满足这一要求，而这些技术不需要特殊的结构即可适应。但是，这肯定会推动设计决策。

9. 公司的目标是雇用廉价的劳动力以最大化利润。
   该要求表明可用性将很重要，但同样，设计更关注而不是架构特征。

从前面的要求中得出的第三个体系结构特征是性能：没有人愿意从性能不佳的三明治店购买，尤其是在高峰时段。但是，性能是一个微妙的概念—架构师应设计什么样的性能？

我们还希望结合可伸缩性数字来定义性能数字。换句话说，我们必须建立没有特定规模的性能基准，并确定给定数量的用户可接受的性能水平。通常，架构特性会相互影响，从而迫使架构师彼此定义关系。

隐式架构

需求文档中并未指定许多架构特征，但是它们构成了设计的重要方面。系统可能要支持的一个隐式架构特征是可用性：确保用户可以访问三明治站点。可靠性与可用性密切相关：可靠性确保网站在交互过程中保持正常运行—没有人愿意从继续断开连接的站点购买产品，从而迫使他们重新登录。

安全似乎是每个系统的隐含特征：没有人愿意创建不安全的软件。但是，可以根据关键程度对其进行优先级排序，这说明了我们定义的内在联系。如果安全性影响设计的某些结构方面并且对应用程序至关重要或很重要，则架构师会将安全性视为架构特征。

对于硅谷三明治，架构师可能会假设付款应由第三方处理。因此，只要开发人员遵循一般的安全习惯（不将信用卡号作为纯文本传递，不存储太多信息，等等），架构师就不需要任何特殊的结构设计来适应安全性；在应用中进行良好的设计就足够了。每个架构特征相互影响，导致架构师过度说明架构特征的共同陷阱，这与未充分说明架构特征一样有害，因为这会使系统设计过于复杂。

硅谷三明治需要支持的最后一个主要架构特征包括需求中的几个细节：可定制性。请注意，问题域的某些部分提供了自定义行为：配方，本地销售和可能在本地被覆盖的指示。因此，架构应支持促进自定义行为的能力。通常，这将属于应用的设计。但是，正如我们的定义所指出的那样，部分依赖自定义结构来支持它的问题域进入了结构特征领域。但是，此设计元素对于应用的成功并不关键。重要的是要注意，选择架构特征时没有正确的答案，只有不正确的答案：

在架构上没有错误的答案，只有昂贵的答案。

架构师可以设计一种架构，该架构在结构上无法适应可定制性，因此需要设计应用本身来支持这种行为。架构师不应该过多地强调发现完全正确的架构特征集，开发人员可以通过多种方式实现功能。但是，正确识别重要的结构元素可能有助于简化或更优雅的设计。架构师必须记住：没有最佳的架构设计，只有最差的权衡取舍。

架构师还必须优先考虑这些架构特征，以尝试找到最简单的必需集合。一旦团队在确定架构特征上走了第一步之后，一个有用的练习就是尝试确定最不重要的一个-如果您必须消除一个，那会是什么？通常，由于许多隐式架构支持普遍成功，因此架构师更倾向于选择显式架构特征。我们定义对成功至关重要或最重要的方法，可以帮助架构师确定应用是否真正需要每种架构特征。通过尝试确定最不适用的方法，架构师可以帮助确定关键需求。对于硅谷三明治，我们确定的哪个架构特征最不重要？同样，不存在绝对正确的答案。但是，在这种情况下，解决方案可能会失去可定制性或性能。我们可以消除可定制性作为一种架构特征，并计划将这种行为实现为应用设计的一部分。在运维架构的特征中，性能对于成功至关重要。当然，开发人员并不是要构建具有糟糕性能的应用，而是要建立一个不将性能置于其他特性（例如可伸缩性或可用性）之上的应用。