当我还是一名日日夜夜编写源代码的开发人员时，我对架构以及解决方案架构师在设计系统时所做的事情有一个了解。它是关于根据一些模式和最佳方法设计源代码，搜索新组件以及现有组件的更改。但是我的方法太像开发人员了，没有考虑业务需求、要求和目标。在担任解决方案架构师多年后，我回首过去，对我当时的做法微笑。
而且，每当我遇到开发人员时，他们都对我公司的解决方案架构感兴趣。我总是简短而有效地解释它，但在大多数情况下我需要更多。我需要更多时间、一些手边的用例以及一个可以用来揭示概念、想法和方法细节的好例子。这是我写这篇文章的主要原因——我想给那些想成为架构师的人一些东西，作为他们在解决方案架构的美好旅程中的第一个参考和步骤。
最好的理解方式是举个例子。
没有比接受一项任务并展示一些抽象需求如何转化为满足业务需求和目标的解决方案更好的理解方式了。我将使用架构套路来涵盖解决方案架构师在设计软件系统时通常所做的一切。如果您仍然熟悉 Architecture Katas 的想法，我建议您查看https://www.architecturalkatas.com并亲自尝试一下。
免责声明：请记住，我的文章涵盖了冰山一角，解决方案架构师在不同项目阶段处理许多其他方面。我计划在未来的作品中说明它们，但这只是大多数解决方案架构师在设计新系统时遵循的高级流程。
假设我们从业务代表那里收到一份提案请求，他们想要以下内容：
一家新的医疗创业公司急于开发患者监护系统。该业务旨在创建一个创新的患者生命体征监测系统，用于测量 ECG、心率、体温、SPO2 和血压。
- 该系统将成为针对三类用户的复杂解决方案：患者、护士和医生。每个用户都需要有一个监视器来查看数据。
- 对于患者来说，需要一个能显示该患者生命体征的患者监护仪；对于护士——护士的监视器，在一个视图中显示有关多个患者的信息；对于医生 — 医生的监视器，上面有他的病人列表，可以选择其中任何一个并查看病人的生命体征。
- 该公司的主要优势是以最低成本提供系统，因为使用无线设备进行测量。此外，该公司不会开发其硬件，但会支持与多家供应商现有测量硬件的集成。
作为解决方案架构师，我们应该致力于这项任务并指导我们的利益相关者。架构师必须满足业务需求和目标以及关键利益相关者的要求。试想一下，如果企业的某个人投资并向整个公司做出投资将带来价值的承诺。满足他们的要求和目标对我们建筑师来说有多重要？
解决方案架构师如何使用业务上下文
作为人，我们有目标。有些人想要更高的薪水，有些人想要获得新工作机会的动力，还有一些人想要出名——在所有这些情况下，人们都会将其转化为目标。如果你有一个目标，你就会找到实现它的方法。如果你没有目标，你的生活不会有任何改变。我不想听起来像一个激励教练；我想表明公司和企业都有自己的目标。企业希望在未来得到很多东西：更好的销售、获得新客户、开拓新市场、满足未来的法律和政府限制等。另外，我想补充一点，任何健康的组织都必须有目标。如果一个组织没有它们，这是走向终结的第一步。
注意：当我们拿到 Kata 格式的任务时，总是有足够的空间来容纳未知和不确定性。如果它是真正的套路方式，我们可以使用假设方法，我们在其中构建猜测/假设列表并围绕它做出决策。但在我的文章中，我认为我们可以与业务代表和其他利益相关者交谈，提出问题并获得答案。
在制定解决方案时，我们应该尽可能多地了解上下文。在上下文中，我指的是以下概念：
- 业务驱动因素和业务目标
- 商业模式
- 一些限制：它可以是技术或业务类型
以下是我向业务代表提出的第一个问题以及他们的回答：
如果我们仔细研究我们的 Medical Startup 项目并处理业务代表的回答，我们将发现以下业务目标和驱动因素：
在与企业交谈后，我们可以确定一些限制条件：
解决方案架构师如何分析需求？
上图医疗启动解决方案的系统上下文视图
我总是建议在开始的某个地方构建上下文视图，因为它可以帮助解决方案架构师理解以及更重要的是可视化所请求的业务需求。
考虑到项目的规模和需求的复杂性，我会使用C4模型。有时很难选择使用什么来模拟您的解决方案，这对我以后的文章来说又是一回事。
在起点，我们有以下愿景：
- 我们有一个医疗组织，它将使用我们的解决方案从医疗设备收集数据，并为我们的最终用户显示所有需要的统计数据和数据
- 每个医疗组织都可以具有以下角色：医生、护士和患者。他们每个人都有监视器来查看他们的数据。
- 我们的解决方
我们还提出了几个问题（在上一节中提到过），我们知道：
- 几乎每个医疗机构都将拥有现有数据和现有系统：在大多数情况下，它将是 CRM（客户关系管理）、EHR（电子健康记录）和身份提供者系统。我们必须尽可能多地利用这种能力
- 我们会有医疗设备的硬件供应商，在我们的解决方案范围内不需要在硬件部分下功夫。
- 有一个现有的 Azure AD 订阅，企业希望从中获得尽可能多的优势。
由于我们有一个可以回答我们问题的联系人（请记住我在本文开头提到的内容），这里有一个表格显示了我询问的有关功能需求的内容以及我得到的答案类型：
上图企业的第一组问题
在任何情况下，并非所有功能需求对于架构都是必不可少的。一些需求我们几乎可以用任何风格或模式集来实现，但其他需求则需要架构师付出一些额外的努力。此类需求有一个名称——架构重要需求。长话短说，ASR（架构重要需求）可能会导致关键的架构决策。在分析了利益相关者提供的所有初始需求和要求后，以下是 ASR 列表：
ASRs
请记住，大多数功能需求不会对架构产生任何关键影响。我们可以使用任何架构实现功能性史诗/用户故事。通常，对架构至关重要的是架构特征（质量属性）和非功能需求。
解决方案架构师如何识别关键质量属性（或架构特征）
现在有许多不同的架构风格和模式可供选择，其中有许多用于计算、数据库、缓存和其他解决方案组件的选项。我们几乎可以用其中的任何一个来实现业务需求，功能部分将被覆盖并根据业务需求工作。 问题是它的效果如何。我们的解决方案的可扩展性、安全性和可用性如何？它是否满足业务需求？
可扩展性、可用性、性能、可靠性等方面有很多定义。不过，我仍将使用质量属性术语，因为它在我公司的使用比其他人多（尽管我更喜欢架构特征命名）。我不想列出架构师通常考虑的所有质量属性，因为您可以自己找到它们。相反，我会提供几种方法来帮助确定解决方案的重要质量属性：
- 在大多数情况下，业务目标隐藏着重要的系统质量和特征。
- 发现过程，在此过程中，架构师与企业交谈并确定非功能性需求，确定它们的优先级，并提取关键质量属性。例如，您可以使用质量属性研讨会格式或利益相关者访谈。我将在以后的文章中解释所有可能选项之间的区别。在当前的帖子中，我假设所有利益相关者同时都没有空，我必须发送我的问题才能得到他们的答案。
- 业务领域还意味着某些质量属性（架构特征）对于系统来说非常关键。例如，如果我们与医疗和保险领域合作，数据安全将毫无疑问地列在清单上。
让我们用业务目标来处理第一部分，并尝试了解我们是否可以确定对业务和最终解决方案有意义的东西。“创建一个创新的患者生命体征监测系统，可以测量 ECG、心率、体温、SPO2 和血压。” 没有关于用户数量、数据量、区域和计划可用性的任何信息，但如果我们深入了解解决方案，我们将意识到我们拥有医疗设备，而且很可能有成千上万的患者使用传感器几乎每秒都在发送信号。最终，这将意味着我们的解决方案必须能够处理大量传入数据，将其保存并用于未来分析。总而言之，该解决方案必须具有适当的可扩展性和弹性特征。
除了功能需求，我们还可以与业务人员交谈，询问有关非功能需求的问题，并获得有助于我们识别重要系统质量属性的答案。
第一部分处理需求的总结
在分析业务上下文和功能需求、识别架构重要需求、获取非功能需求并了解对系统质量属性至关重要的内容后，我们有以下内容：
用户角色：
业务驱动力和目标：
约束：
功能架构重要要求：
非功能性要求：
确定的质量属性（架构特征）：
第 2 部分，设计解决方案
假设及其对架构的重要性
如果你在某个理想世界中从事项目/产品，你可以跳过这一部分：你对所有问题都有答案，你没有任何风险，你几乎可以立即开始设计。不幸的是，即使在我的例子中，我也只能得到一些问题的答案。原因很简单——项目利益相关者和业务代表并不像我们那样无所不知。他们可以猜测并假设某事会或不会发生。如果他们这样做，我们也可以这样做。
架构假设是我们有几个可能的场景的地方。我们不知道会发生什么，但我们将赌注押在一个选项上。因此，我们的解决方案将取决于我们的选择。
我总是建议与负责该领域的利益相关者一起验证任何假设。如果架构师孤立地做某事，他失败的几率会呈指数级增长。
以下是我与项目利益相关者一起做出并验证的假设列表：
每当我准备假设时，我必须知道如果某些事情没有像我们假设的那样发生，它会对我们的解决方案产生怎样的影响。Impact 列对此非常关键。我建议你提前准备好。
在我们的案例中，我们收集了所有假设并与项目利益相关者进行了讨论。这意味着该假设并没有隐藏在架构师的口袋里。每个人都知道它们，并且理解如果其中一个假设不会发生，我们的方向将如何改变。
解决方案架构师如何做出架构决策和分析权衡
我们有架构的重要需求、质量属性、约束和一系列假设。你们中的一些人可能认为我们可以开始设计我们的解决方案。这是新架构师在设计部分工作时常犯的错误之一——他们试图在大脑的无意识部分绘制蓝图，其中包含所有需求和决策。虽然这种基于直觉的方法适用于经验丰富的架构师（如果你有超过十年的架构师角色），但我提倡人们使用更正式的方法，我们可以结合决策制定方法、架构决策日志和权衡分析。
您还可以在互联网上找到质量属性驱动设计方法。这种技术很棒，但从我的角度来看，我们不能只关注质量属性，因为一些功能需求可能对架构很重要，也会影响目标设计。
我的方法基于以下步骤：
- 我画了一个表格，其中包含以下几列：架构决策、需求/原因、替代选项和视图，我们可以在其中看到此架构决策
- 我接受所有 ASR（包括功能需求和与质量属性相关的 NFR）并逐一做出决定。请记住，在大多数情况下，您的决定与您的要求相关，但有时您可以做出权衡，您可以提出一些建议，并且您有充分的理由。
- 当我记录一个需求（无论它是什么）时，我都会引用这个需求。如果您使用 Microsoft Word、Google Docs 或 Confluence，它甚至可以是可点击的链接。不幸的是，由于 Medium 的限制，我只能添加表格作为屏幕截图。因此，引用将不可点击。但它们在那里，带有 # 前缀——例如 ASR#1 或 NFR#1
- 我在表中区分了决策和权衡。您可以使用任何您喜欢的东西。我用另一种颜色来记录这样的记录。
- 每当我记录一个决定时，我都会预见我将使用哪些架构视图来展示和解释该决定。
当我们处理实际项目时，我建议为每个决策创建一个单独的页面，您可以在其中放置更多上下文、将备选方案与某些标准进行比较并总结您的分析。在我的示例中，我们使用了 Kata-way，如果我对每个决定都进行了过多的描述，那么这篇文章将是不定式的。
这取决于您的项目协议：在何处以及如何记录架构权衡，但我在我的示例中将它们放在同一个表中。架构权衡也是决策，但它们更多地是关于我们做出可能违反某些需求或只能满足其中少数需求的决策的情况。另一个著名的案例是当两个或多个需求发生冲突时，我们必须做出权衡决定。
上图是做出和记录的决定列表
我希望您不要过分关注每个决定。很可能，你可以提出比我更好的建议。本文的目的是展示我的思维方式，它可以应用于任何解决方案设计过程。无论如何，如果您看到更好的选择，请随时发表评论——我将不胜感激。
让我们做出一个决定并详细描述它。在与企业交谈后，我们知道付款将基于设备数量和使用我们解决方案的医疗机构的最终交易金额。表示医疗机构不能预先支付，比如1000美元，使用我们的服务。取而代之的是，它将使用我们的解决方案一个月，我们将根据交易数量计算它使用我们的解决方案的数量，然后我们将向该医疗机构发送账单。我们可以有什么样的选择？
- 我们可以对计算部分使用无服务器方法——AWS Lambda。此选项非常有效，因为 AWS 将根据 Lambda 调用次数向我们收费。假设一个组织很小，他们没有那么多病人、护士和医生。在那种情况下，设备的数量将相对较少——而且他们支付的费用将低于其他大型医疗机构。
- 有一个 AWS EKS 集群的选项，其中包含 EC2。如果我们选择 EKS with EC2 setup，我们需要提前计算负载和交易量。即使我们这样做，我们的计算能力也很有可能无法 100% 地发挥作用。这个选项看起来不适合我们的商业模式。
- 我在这里可以描述的另一种选择是带有 Fargate 引擎的 AWS EKS 集群。如果我们将此选项与选项 2 进行比较，它看起来很有希望，因为无需提前计算潜在负载。但是，它仍然会给我们带来一些挑战，以衡量每个医疗机构使用了多少我们的能力。
好吧，我们有需要/理由，我们必须做出决定。考虑到所有可能选项的优缺点，我决定使用无服务器方法和 AWS Lambda 进行计算。您可以在表中找到编号 0。
我只想从表格中解释我的一些决定。如果我涵盖所有这些，这篇文章将成为一本书。不管怎样，我希望你记住做决定的想法——你有一个理由，考虑不同的选择，然后做出决定。一个决策示例就足够了。
如果您的设计中有某些东西并且无法解释原因：您无法将其与需求联系起来，您无法参考权衡——很可能是您做错了什么。如果您可以详细说明您在做什么以及如何做，但无法解释原因——您可能会白花钱，在不必要的项目上工作，并且没有解决系统最关键的架构重要需求和质量属性。
解决方案架构师如何设计他们的解决方案
一旦我们有了决策列表，我们就可以开始下一个旅程并开发我们的解决方案。您可以在 Internet 上找到各种方法和途径，但它们都有一个共同点——您使用的是迭代方法。相信我。您不能设计一些东西（选择技术、绘制矩形和线条），然后尝试为此找到适合您要求的应用程序！它永远不会工作。您应该查看需求和决策日志，并为它们中的每一个添加一个新的绘图笔划到您的设计中。
一种流行的方法是质量属性驱动设计，它在底层具有相同的迭代概念。尽管这种方法效果很好，但我看到了一些差距——过于关注质量属性。在某些情况下，一个质量属性可用的十个场景中只有一个可能是关键的。当您根据 ASR 和质量属性场景设计解决方案时，我更喜欢这种方法。
如果我想在源代码中解释我所指的概念，它会是这样的：
desicionLogRecords.stream().forEach(decision -> { |
我们最初在上下文视图中拥有的内容可以轻松迁移到其他视图。如果您遵循 C4 模型思想，请记住每个视图都是其他视图的容器。当我们从一个视图移动到另一个视图时，我们会放大以显示并提供更多细节。让我们使用上下文视图作为解决方案结构视图的模板。
对于某些人来说，这可能是第一次听到解决方案结构视图命名。我在公司习惯了这种命名和方法。它与容器视图相同，但涵盖了整个解决方案，而不是从上下文视图中显示每个子系统的容器。但您也可以将其视为容器视图。
让我们记住我在文章的第一部分中展示的上下文视图：
让我们记住我在文章的第一部分中展示的上下文视图。
上图我们医疗初创公司的背景视图
当我们查看第一个决定及其要求时，它们代表了日志中以下所有记录的一般概念：我们使用 AWS 作为云提供商。因此，我们解决方案结构视图中的所有组件都是 AWS 组件。我们可以跳过它并转到表中的其他行。
让我们跳到列表中的以下两个决定：
- B2B 订阅取决于设备/传感器的数量，只需为使用的计算/处理时间付费：计算的无服务器 (AWS Lambda) 方法和存储的 AWS Timeseries
- 使用Kinesis Firehose + Kinesis Data Analytics将数据转换为正确的格式并通过Kinesis Data Streams和AWS Lambda传递到数据库。
如果我们在我们的解决方案结构视图中显示这些决定，我们将得到如下内容：
上图第一次迭代后的解决方案结构视图
请原谅我，但我不会展示所有决策如何出现在解决方案结构视图中——如果我这样做，文章将变得庞大，你可能会在中间的某个地方感到厌倦。我的目标是展示解决方案架构的原则和概念。一旦你得到它，所有的技术细节都会显得简单。假设我们检查了我的决策日志中的所有记录。最后我们会得到什么：
上图所有设计迭代后的解决方案结构视图的最终版本
也许我想得太多了，在我的写作中说得太多了，但我想你们中的一些人能找到比我更好的东西来满足某些需求。随时分享它；如果我们有建议其他想法和选项的评论，本文将会改进。
概括
惊人的！我们做到了！我们分析了需求并确定了业务目标、ASR 和质量属性。我们制定了架构决策并为医疗初创公司设计了解决方案。我们使用了解决方案架构思维模式，这将持续多年。
请记住，理解业务在前，架构决策在后，设计总结了前两部分。
让我们进行最终检查，以确保我们的解决方案能够满足我们的业务目标。
详细点击标题