定义：
软件中的设计模式（通常）是简短的描述，用于捕捉过去证明是成功的实践。它们不是具体的软件，而是在某些情况下应用的一种模板。它们通常不是规定性的，而是建议性的，并且包括关于何时最适合使用它们的指导，并提供来自现有系统的示例。它们最重要的用途是描述对象或系统与其环境（即其他对象或系统）的交互。设计模式可以出现在系统设计的不同级别，从低级编程到系统系统。在后一层，它们与界面设计和耦合最为相关。
关键词：
耦合，设计模式，接口
MITRE SE 角色和期望：
MITRE 系统工程师 (SE) 应了解信息技术 (IT) 密集型系统的设计模式的一般原则和最佳实践。他们应选择和推荐适合应用程序的模式，了解出现的挑战和选择，就设计模式选择的适用性向政府提供建议，并了解企业环境中界面设计的问题和挑战。
背景
设计模式的概念通常归功于建筑师 Christopher Alexander 的工作，并被 Kent Beck 和 Ward Cunningham 改编为软件。 1995 年，流行的书籍设计模式（其作者通常被称为“四人帮”（GOF））建立了一组持续使用的模式，并提供了描述模式的“模式”[1]。这 23 种模式分为创造型、结构型和行为型。已经定义了许多其他模式，以及其他类别，例如用户界面。
例如，一个 GOF 模式是抽象工厂，这是一种创建模式，它提供了一个用于创建新对象的接口，而调用者并不知道正在创建的对象的具体类型。这可以用于实现不同的外观和感觉，只需对程序进行最小的更改。其他示例是代理结构模式，其中一个对象成为另一个对象的代理（具有相同的接口），通常用于远程过程调用；单例模式，其中一个类只允许创建自己的一个实例，通常用于管理共享资源；和中介者行为模式，它允许类之间的松散耦合，因为它是唯一一个对其方法有详细了解的类。
与审查接口调用的细节相比，设计模式使对软件设计的审查和讨论能够在更高和更抽象的层次上进行——“你应该在这里使用单例模式吗？”或“抽象工厂模式有帮助吗？”
GOF 模式有几个共同点：它们是根据面向对象的软件定义的，它们（通常）描述一个对象与其环境（例如，其他对象）的交互，它们通常用在一个内部设计中。单个应用程序（即本地调用环境）。
然而，模式也可以在更广泛的设计层次上进行查看，而 MITRE SE 更经常地涉及到这方面。与审查组件之间或更高级别的系统之间的接口相比，MITRE SE 不太可能参与系统组件的详细内部工作的开发。这需要一组设计模式，这些模式专注于跨系统边界建立连接的方式。许多 GOF 模式不会直接应用。
企业工程面向服务环境中的设计模式
在为大型企业服务环境进行设计时，会出现两个考虑：（1）用户可能会以设计者没有预料到的方式将服务、接口等放在一起，以及（2）任何接口更改都会影响更大的用户集.深思熟虑地使用设计模式可以帮助解决这两个问题。扩展到企业的第三个问题是服务通常必须处理（当前）未知且潜在的大量用户。设计模式在直接处理这个问题时用处不大。
在企业环境中，当考虑系统到系统的接口时，可以扩展设计模式的概念，以包含有关如何管理接口中的耦合的更一般的指导。作为一般规则，只要可能，松耦合优于紧耦合。松散耦合意味着接口一侧实现的变化不会影响另一侧的实现。例如，在具有必须分发给用户的查找表的字段中使用代码不是松散耦合。此外，松散耦合的接口不应锁定会抑制可扩展性的特定限制。作为一个简单的例子，在联系信息的界面中，只允许一个（或两个）10 位数字的电话号码可能是不够的。一个更可扩展的接口可能允许任意长度的不确定长度的电话号码列表。
松散耦合将接口的用户与实现中的更改隔离开来。例如，一个设计良好的界面应该能够向界面添加更多参数，同时在没有新参数的情况下仍然可以生成和接受消息。这允许增长和创新，而不会使以前版本的界面的用户陷入困境。但是，另一方面，必须谨慎管理此扩展机制，否则仅参数不同的受支持接口的数量可能会变得很大，并且维护这些接口可能会淹没向后兼容性的价值。
示例接口标准化工作
Cursor on Target (CoT) [2] 是企业努力简化接口集合并提供松散耦合的一个示例。美国空军在许多组件之间拥有大量紧密耦合的点对点接口。 John P. Jumper 将军（前空军参谋长）启发 MITRE 提出了一组数据元素，可以满足大多数用户的大部分需求。 MITRE 研究了几个月的消息，发现有少量数据元素被重复使用。 CoT 以易于生成和解析的 XML 格式对这些元素的定义进行了标准化。它提供了兼容的扩展，因此可以添加新元素而不会破坏现有用户。
国家信息交换模型 (NIEM) [3] 是一个基于 XML 的信息交换接口。它源于全球司法 XML 数据模型，是司法部和国土安全部之间的合作项目。它已被许多州和国防部采用。它提供了一个信息元素词汇表，合作伙伴可以从中选择创建消息。
与 MITRE 系统工程能力模型 (SE CM) 保持一致
具有设计模式的系统工程工作与 MITRE SE CM [4] 中的“架构”（第 2.3 节）和“软件和信息工程”（第 4.7 节）能力最接近。在前者中，设计模式可以成为讨论、可视化、比较和记录架构界面决策的有用工具。在后者中，因为设计模式现在是软件工程中一种成熟的范式，所以对技术和术语的理解有助于促进客户/用户和软件专家之间的沟通。
最佳实践和经验教训
以下实践规则可以看作是企业级以及详细实现级的接口设计模式。
- 避免接口的复杂性。复杂的接口通常不能很好地扩展。复杂性被推送给所有用户，处理它的技能可能会有所不同。例如，不是以 10 种可能不同的格式提供纬度和经度，每种格式都必须由用户处理，而是以单一格式提供。如果一个接口过于复杂，则很可能会被误解，或者开发人员会复制用户端的次优实现。复杂性会导致错误，从而导致可能无法纠正的不良性能，甚至可能成为安全风险。
- 尽可能使用松散耦合的接口。松散耦合意味着接口一侧实现的变化不会影响另一侧的实现。这为双方提供了极大的自由来进行改进并保持开发计划不连贯。严格的时序要求或软件版本要求可能是需要重新评估和放宽这种做法的考虑因素，但在这种情况下应该明确说明并记录在案。
- 只有在性能需要时才使用紧密耦合的接口。紧密耦合会导致代码有缺陷和脆弱。紧密耦合的一个例子是 Link-16 接口，因为它是一个战术链接，所以使用一个数字来表示飞机的类型。这将用户与特定版本的转换表联系起来。如果表格在一侧更新，则用户可能会留下一个无意义的数字，直到表格也被更新。当然，更广泛的通信协议可以明确地携带飞机上的所有信息，但带宽限制可能会禁止将其作为替代方案。
- 如果可能，从松散耦合开始设计。即使在使用紧耦合的情况下，初始设计也可以从松耦合接口开始。记录使用紧密耦合的原因。这类似于以独立于数据库管理系统 (DBMS) 的方式定义逻辑模式，但在依赖于 DBMS 的物理模式中实现它。对于系统的系统，这可能是一个有用的模式。
- 关注接口中的数据一致性，而不是内部表示。在 1990 年代，政府组织试图在所有应用程序中强制执行数据一致性，甚至指定如何在应用程序及其数据库中表示数据。这从未实现。最近，重点是为数据交换创建通用定义，让应用程序可以自由选择如何在内部表示数据。事实证明，这是一个更容易实现的目标。
- 认识到数据表示的差异是由数据的不同用途造成的。例如，考虑一把枪。射手想知道它的射程、口径等。托运人想知道它的大小、重量等。财务想知道它的成本、估计寿命等。同样的枪在不同的系统中自然会有不同的表示。强制所有系统上的所有特征将是繁重的。但是，可以通过组合模式来实现数据的意想不到的创新使用，以创建基于现有表示的新数据表示。
- 在设计界面时，请考虑 80/20 规则。实现大多数用户大部分时间需要的 80%（左右）可能会更好，特别是如果这可以通过简单的界面快速完成。这减少了实施的成本和时间。
- 构建扩展接口的能力。一些用户需要至少达到剩余 20% 的一部分，并且无论如何，界面必须随着时间的推移而增长和变化。松散耦合的接口应该构建兼容扩展的机制，以便可以在不影响不需要扩展的用户的情况下进行更改和添加。
- 考虑可扩展接口的治理。接口的扩展会创建必须管理的多个版本/副本。考虑这样做的理由并理解这样做的影响。
- 不要忘记界面中的语义理解水平。有人能够正确解析您的界面很好，但也必须对数据元素的含义达成一致。
- 让开发人员参与系统接口的开发。那些将实现接口的人应该参与设计，因为他们可能对可能抑制可扩展性或导致其他问题的决策有洞察力。
References and Resources
- Gamma, E., R. Helm, R. Johnson, and J. Vlissides, 1995, Design Patterns: Elements of Reusable Object-Oriented Software, Boston, Mass. Addison-Wesley Longman.
- Miller, R. W. and D. G. Winkowski, June 2007, Loose Couplers as an Information Design Strategy, The MITRE Corporation.
- National Information Exchange Model, accessed August 5, 2014. (By the way, they are looking for NIEM design patterns.)
- The MITRE Institute, September 1, 2007, MITRE Systems Engineering Competency Model.
Additional References and Resources
- Bell, M., 2010, SOA Modeling Patterns for Service Oriented Discovery and Analysis, Hoboken, N.J., John Wiley & Sons.
- Erl, T., 2009, SOA Design Patterns, New York, Prentice Hall.
- Fowler, M., 2002, Patterns of Enterprise Application Architecture, Addison-Wesley.
- Hohpe, G., and B. Woolf, 2003, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Boston, Mass., Addison-Wesley Longman.
- Van Welie, M., A Pattern Library for Interaction Design, accessed April 14, 2014.
- Vora, P., 2009, Web Application Design Patterns, San Fransisco, Calif., Morgan Kaufmann Publishers.
原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…