When building a new software product, it is crucial to pick the optimal architecture as early as possible. The right architecture supports the engineering team in building the product. Poor architecture choices hinder development and may lead to expensive rework in the future.

在构建新的软件产品时，至关重要的是尽早选择最佳架构。 正确的体系结构可支持工程团队构建产品。 糟糕的体系结构选择会阻碍开发，并可能导致将来昂贵的返工。

In this article I’d like to share an approach to designing a future-proof software architecture that has helped me to come up with simpler designs, ship new functionality faster, and avoid big architecture changes as the products evolved.

在本文中，我想分享一种设计面向未来的软件体系结构的方法，该方法可以帮助我提出更简单的设计，更快地发布新功能，并避免随着产品的发展而对体系结构进行重大更改。

What I particularly like about that approach is that it scales up and down depending on the project size (product, service, or just a large feature), and that it can be as rigorous or as informal as appropriate for the engineering culture in an organisation.

我特别喜欢这种方法的是 它可以根据项目规模(产品，服务或只是一个大功能)进行缩放，并且可以针对组织中的工程文化进行严格或非正式的调整。

Let’s briefly look at two ways how an engineering team may come up with a software architecture for their product: ad hoc vs planned and then talk about the approach itself and look at an example how it can be used.

让我们简要地看一下工程团队如何为他们的产品设计软件体系结构的两种方式：即席与计划的关系，然后讨论该方法本身，并举例说明如何使用该方法。

临时架构与计划架构 (Ad Hoc Architecture vs Planned Architecture)

Ad hoc architecture emerges when the dev team just hacks ahead and developers are building the product according to their own assumptions, opinions, and preferences without much of a plan.

当开发团队向前攻一步，并且开发人员根据自己的假设，观点和偏好在没有太多计划的情况下构建产品时，便出现了临时架构 。

This is alright for small projects with a short life and no plans for further evolution, such as marketing campaign websites.

对于寿命短，没有进一步发展计划的小型项目(例如营销活动网站)，这是不错的选择。

Planned architecture is the opposite. It is the product of the design process ran by the engineering team.

计划的架构则相反。 它是工程团队运行的设计过程的产物。

Planned architecture can be driven:

可以驱动计划的架构：

• either by subjective factors —personal experience, preferences and assumptions of the engineers in the team;

  通过主观因素-团队工程师的个人经验，偏好和假设；

• or by objective factors — the organisation goals and the conditions of the environment where the product is going to be used.

  或通过客观因素-组织目标和将要使用该产品的环境条件。

The issue with the former case is that it doesn't guarantee that the team would come up with the architecture optimised for achieving the actual organisation goals. The reason is that developers would be proposing technologies and design patterns based on their opinions but there won’t be a shared set of criteria for them to evaluate available options and pick the most appropriate ones.

前一种情况的问题在于，它不能保证团队会提出优化的架构以实现实际的组织目标。 原因是开发人员将根据他们的意见提出技术和设计模式，但不会有一套共享的标准供他们评估可用选项并选择最合适的选项。

On the contrary, the latter case encourages the team to first agree on a shared set of criteria derived from the analysis of the organisation goals and the environment conditions.

相反，后一种情况鼓励团队首先就从组织目标和环境条件的分析得出的一组共享标准达成共识。

In addition, it reduces the impact of subjective factors on the outcome and encourages engineers to go beyond their current experience and knowledge to look for the optimal technical solutions.

此外，它减少了主观因素对结果的影响，并鼓励工程师超越现有经验和知识去寻找最佳技术解决方案。

As a result, the team increases their chance of designing the architecture optimised for achieving the organisation goals and reduces their chance of having to do expensive architecture changes in the future.

结果，团队增加了设计为实现组织目标而优化的架构的机会，并减少了将来必须进行昂贵的架构变更的机会。

基于非功能需求分析的架构设计方法 (An Approach to Architecture Design Based on Non-Functional Requirements Analysis)

The approach to architecture design that has been working well for me consists of three steps:

对我来说一直有效的体系结构设计方法包括三个步骤：

1. Identification and analysis of the non-functional requirements for the product.

   识别和分析产品的非功能性需求 。

2. Selection of the relevant software quality attributes for the product and setting their targets.

   选择产品的相关软件质量属性并设置其目标。

3. Selecting technologies and design patterns that would meet the targets for the relevant quality attributes to satisfy the non-functional requirements.
   选择满足相关质量属性目标的技术和设计模式，以满足非功能性需求。

For those who are not familiar with the terminology, non-functional requirements are the criteria for evaluating how a software system should perform rather than what it should do. An example would be a requirement for a web API endpoint response time to be under 200ms.

对于那些谁不熟悉的术语， 非功能性需求是评价一个软件系统应如何执行，而不是它应该做的是什么标准。 例如，Web API端点响应时间必须在200毫秒以下。

When we say that a software product should be “secure”, “highly-available”, “portable”, “scalable” and so on, we are talking about its quality attributes.

当我们说一个软件产品应该是“安全”，“高度可用”，“便携式”，“可扩展”等时，我们在说的是其质量属性 。

In other words, a software product must have certain quality attributes to meet certain non-functional requirements.

换句话说，软件产品必须具有某些质量属性才能满足某些非功能性要求。

步骤1.识别和分析非功能需求 (Step 1. Identification and Analysis of Non-Functional Requirements)

Product managers and business analysts rarely can provide engineers with a comprehensive list of non-functional requirements: it is difficult for many people to uncover their implicit expectations and assumptions. In addition, some non-functional requirements are related to purely technical aspects of the product and the Product team may be completely unaware of them.

产品经理和业务分析师很少能为工程师提供全面的非功能性需求清单：许多人很难发现他们的内在期望和假设。 另外，一些非功能性需求与产品的纯粹技术方面有关，并且产品团队可能完全没有意识到。

As a result, the engineering team has to lead this process themselves.

结果，工程团队必须自己领导这个过程。

Working with Product, Design and possibly Marketing, Support, Analytics, Legal and other departments, engineers need to walk through what the new product is meant to be doing to identify expectations, assumptions and requirements to how the new product should perform its functions.

与产品，设计以及可能的市场，支持，分析，法律和其他部门合作，工程师需要仔细研究新产品的含义，以识别新产品应如何执行其功能的期望，假设和要求。

Please note, that it doesn’t have to be a series of formal meetings. Sometimes a couple of quick chats with representatives of those departments is enough to clarify the details and move to the next stage.

请注意，不必一定要召开一系列正式会议。 有时，与这些部门的代表进行几次快速交谈就足以弄清细节并进入下一阶段。

Let’s look at an example where a team is tasked with developing a mobile app for streaming video content. This leaves a lot of room for interpretation.

让我们看一个示例，其中一个团队负责开发用于流式传输视频内容的移动应用程序 。 这就留下了很大的解释空间。

After a conversation with the Product team and asking them questions like:

与产品团队交谈后，向他们询问以下问题：

• How many customers would you expect in 6-12 months after launch?
  您希望在发布后的6到12个月内有多少客户？
• How many customers do you think will be using this at the same time?
  您认为有多少客户将同时使用此功能？
• How long the videos are going to be?
  视频将持续多久？
• How bad that would be if the product would be down for an hour?
  如果产品停机一个小时，那将有多严重？
• What market are you planning to launch it in the first 12 months?
  您计划在头12个月内在哪个市场推出？

that may be expanded into something like “in 12 months after launch the product must scalable enough to stream video content to 0.5–1M concurrent users 24/7 all over the world”. That would encourage developers to consider only those design patterns and technologies that allow to develop a highly-scalable, highly-available, and fault-tolerant architecture.

可能会扩展为“产品发布后12个月内必须具有足够的可伸缩性，以将视频内容流传输给全球0.5 / 1M 24/7的并发用户”。 这将鼓励开发人员仅考虑那些允许开发高度可扩展 ， 高度可用且容错的架构的设计模式和技术。

Furthermore, Marketing may add to that that the product actually needs to be localisable since it is going to be available world-wide.

此外，市场营销可能还会增加产品的实际需求，因为该产品将在全球范围内可用。

In addition to that, Legal team may require the product to be compliant with the laws of various jurisdictions around the world regarding what video content may and may not be available to various age groups.

除此之外，法律团队可能会要求该产品遵守全球各个司法管辖区关于哪些视频内容可能适用于各个年龄段以及哪些年龄段无法使用的法律。

As the outcome of this step, we have identified five quality attributes potentially relevant for the architecture of the product: scalability, availability, fault-tolerance, localisability, and compliance.

作为此步骤的结果，我们已经确定了与产品架构潜在相关的五个质量属性： 可伸缩性 ， 可用性 ， 容错 性 ， 可 定位性 和合 规性 。

As mentioned above, there is no need to clarify every possible aspect of the future product behaviour at this stage. Engineers should be pragmatic: as soon as the essential non-functional requirements have been identified and analysed and the team has reached the point of diminishing returns, it may be the time to move to the next step.

如上所述，在此阶段无需澄清未来产品行为的每个可能方面。 工程师应该务实：一旦确定并分析了基本的非功能性需求，并且团队已经达到收益递减的地步，那么也许是时候进行下一步了。

步骤2.选择相关的质量属性 (Step 2. Selection of Relevant Quality Attributes)

Having the list of quality attributes from the previous step, developers can select which ones the product architecture should be optimised for and define their targets.

有了上一步中的质量属性列表，开发人员可以选择应针对产品架构进行优化的属性并定义其目标。

Developers may also want to know what quality attributes their product architecture doesn’t have to be optimised for. Then they would know which attributes to sacrifice to meet the important requirements. Candidates for such irrelevant attributes either have no related non-functional requirements or have ones that are easy to meet.

开发人员可能还想知道不必针对其产品架构的哪些质量属性进行优化。 然后他们会知道要牺牲哪些属性才能满足重要的要求。 此类不相关属性的候选人要么没有相关的非功能性要求，要么具有容易满足的要求。

For the example above, the engineering team may decide to optimise for:

对于上述示例，工程团队可以决定针对以下方面进行优化：

• scalability, so the product could handle 0.5–1M concurrent users,

  可扩展性 ，因此该产品可以处理0.5–1M并发用户，

• availability, so it could have, let’s say, 99.995% uptime,

  可用性 ，因此它可以有99.995％的正常运行时间，

• localisability, so its content, support and marketing materials could be available in the most popular 10 (20, 30, etc.) languages in the world.

  可本地化 ，因此其内容，支持和营销材料可能以世界上最流行的10种(20种，30种等)语言提供。

As for the remaining two quality attributes, the team may decide that there is no need to optimise the architecture for them:

至于其余两个质量属性，团队可以决定不需要为它们优化体系结构：

• fault-tolerance, may be achieved together with availability,

  容错 ，可以与可用性一起实现，

• compliance, as content restrictions per geographic location don’t have significant impact on technologies and architecture patterns that are going to be used in the product.

  合规性 ，因为每个地理位置的内容限制不会对产品中将要使用的技术和架构模式产生重大影响。

It is convenient for developers to have a comprehensive list of possible quality attributes to go through and check whether each attribute has any related non-functional requirements for the product. Having such a list greatly simplifies steps 1 and 2.

开发人员可以方便地获得可能的质量属性的完整列表，并检查每个属性是否对产品有任何相关的非功能性要求。 拥有这样的列表大大简化了步骤1和2。

I use the list of 31 quality attributes grouped into eight characteristics that are defined in the international standard ISO/IEC 25010 in the section that introduces a software product quality model:

我在介绍软件产品质量模型的部分中使用了31个质量属性的列表，这些属性分为8个特征，在国际标准ISO / IEC 25010中定义：

• functional suitability: functional completeness, functional correctness, functional appropriateness;

  功能适应性 ：功能完整性，功能正确性，功能适当性；

• performance efficiency: time behaviour, resource utilisation, capacity;

  绩效效率 ：时间行为，资源利用，能力；

• reliability: maturity, availability, fault tolerance, recoverability;

  可靠性 ：成熟度，可用性，容错性，可恢复性；

• usability: appropriateness, recognisability, learnability, operability, user error protection, user interface aesthetics, accessibility;

  可用性 ：适当性，可识别性，可学习性，可操作性，用户错误保护，用户界面美观性，可访问性；

• security: confidentiality, integrity, non-repudiation, accountability, authenticity;

  安全性 ：机密性，完整性，不可否认性，问责制，真实性；

• compatibility: co-existence, interoperability;

  兼容性 ：共存，互操作；

• maintainability: modularity, reusability, analysability, modifiability, testability;

  可维护性 ：模块化，可重用性，可分析性，可修改性，可测试性；

• portability: adaptability, installability, replaceability.

  便携性 ：适应性，可安装性，可替换性。

You can find their definitions either in the free fragment of the official standard, or here. Even though they sound quite abstract, in practice experienced developers quickly pick up what they mean and start using them.

您可以在官方标准的免费片段中或在此处找到其定义。 尽管它们听起来很抽象，但实际上，经验丰富的开发人员会Swift理解它们的含义并开始使用它们。

There are other quality attributes. This Wikipedia article has a few examples. Also, some projects, organisations or business domains may need unique quality attributes.

还有其他质量属性。 这篇Wikipedia文章提供了一些示例。 此外，某些项目，组织或业务领域可能需要唯一的质量属性。

As in the previous step, there is no need to capture every possible quality attribute. Only the relevant ones matter. Four to seven relevant quality attributes may be sufficient to efficiently generate and evaluate design options.

与上一步一样，无需捕获每个可能的质量属性。 只有相关的问题才重要。 四到七个相关的质量属性可能足以有效地生成和评估设计选项。

步骤3.制定架构决策 (Step 3. Making Architecture Decisions)

Having the list of relevant quality attributes and their targets, the engineering team can start generating architecture options. Let’s take a look at some obvious high-level architecture options that may be proposed for the three quality attributes identified in the example above.

有了相关质量属性及其目标的列表，工程团队就可以开始生成体系结构选项。 让我们看一下针对上面示例中确定的三个质量属性可能提出的一些显而易见的高级体系结构选项。

• Scalability: the product can use a CDN to deliver at least static content faster to its users; the videos can be stored in a cloud storage possibly in multiple regions globally to make streaming faster; application servers also may need to be deployed to multiple regions; the databases should to be highly scalable and have to support replication to other regions to avoid high latency when called from the app servers located on the opposite side of the world; part of the backend functionality may be implemented with cloud functions.

  可扩展性 ：产品可以使用CDN更快地向用户交付至少静态内容； 视频可以存储在云存储中，可能在全球多个区域存储，以加快流式传输； 应用服务器也可能需要部署到多个区域； 数据库应该具有高度的可扩展性，并且必须支持复制到其他区域，以避免从位于世界另一端的应用程序服务器调用时产生高延迟； 后端功能的一部分可以通过云功能实现。

• Availability: the product may need to be deployed to several availability zones within each region; deployment strategies should allow deployment without downtime; each region may have to have the copy of all data to be able to run independently.

  可用性 ：可能需要将产品部署到每个区域内的多个可用性区域； 部署策略应允许没有停机的部署； 每个区域可能必须具有所有数据的副本才能独立运行。

• Localisability: the product must support integration with multiple payment methods popular in different countries; it must be integrated with a system for managing UI translations; each content item needs to support multiple localised versions; the product needs to reliably identify the location of a user to know which content is and is not available there.

  可定位性 ：产品必须支持与不同国家/地区流行的多种付款方式集成； 它必须与用于管理UI转换的系统集成在一起； 每个内容项都需要支持多个本地化版本； 产品需要可靠地标识用户的位置，以了解哪些内容在那里存在或不可用。

Having identified the available options, the team can finally select those ones that should achieve the targets for the relevant quality attributes in the most efficient way.

确定了可用的选项后，团队最终可以选择那些应以最有效的方式实现相关质量属性目标的选项。

Even though, that doesn’t guarantee that the product architecture won’t have to change in the future, that still reduces the chance that the changes will be significant and gives the engineers enough information to confidently move forward.

即使这样，也不能保证将来不必更改产品体系结构，但仍可以减少发生重大更改的机会，并为工程师提供足够的信息来自信地向前迈进。

To sum up, having identified non-functional requirements and relevant quality attributes, a product engineering team can generate architecture options and choose the most efficient ones based on analysis rather than on personal preferences and opinions.

综上所述，在确定了非功能性需求和相关质量属性后，产品工程团队可以生成架构选项，并根据分析而不是根据个人喜好和意见选择最有效的方案。

That should help them to achieve the organisation goals faster and avoid significant architecture changes in the future.

这将帮助他们更快地实现组织目标，并避免将来发生重大体系结构更改。

Please note, that this approach is not meant to result in Big Design Up Front or waterfall model. The goal here is to quickly identify the objective criteria that the architecture should be meeting in the foreseeable future, not to lock the design down and substitute real product development with drawing diagrams and writing documents.

请注意，这种方法并不意味着可以使用Big Design Up Front或Waterfall模型。 此处的目标是快速确定架构在可预见的将来应满足的客观标准，而不是锁定设计并用图纸和书面文档代替实际的产品开发。

The approach also scales up and down pretty well, so it can be as rigorous or as informal as the specific product requires it to be. I’ve used it when designing new products, new systems and even just large feature sets.

该方法还可以很好地按比例放大和缩小，因此可以根据特定产品的要求严格或非正式。 在设计新产品，新系统甚至大型功能集时，我都使用了它。

I hope you have found this article useful.

希望本文对您有所帮助。