有关为项目构建高质量体系结构需要考虑的内容的故事。 如何使其沉没，并让客户满意。
下面我们将考虑现实生活中的示例，并尝试从他人的错误中学习。 在此过程中，我们将为解决方案架构师编写一本有用的建议书。 总而言之-从客户的主要要求开始的建筑任务，并伴随进一步的汇报。
本文基于
HolyJS 2018 Piter会议上的Alexey Bogachuk（EPAM的解决方案架构师）的一份报告。 在过场动画中-报告的视频和成绩单。
建筑架构的方法和项目架构师的角色
游泳-我们知道
瑞典船只Vasa的水手说。 他们刚刚驶过，正从沉没的船上逃离，沉船刚刚从人行道降入水中。 Vasa与它有什么关系？
让我们从一个简短的故事开始，使您对构建应用程序体系结构的方法和项目架构师的角色有完全不同的看法。
瑞典国王与建筑师造船商Henrik Hubertsson签订了合同。 根据合同条款，亨里克必须建造一个旗舰店-瑞典舰队的美，这是欧洲最好的战舰。 作为主要赞助商，国王和财政部参与了该船所有主要特征的协调，因此，命令的制定如下：
- 该船应为波罗的海舰队中最大的：长70米，宽10米；
- 您需要三个甲板，可容纳300名士兵；
- 他必须在两排船上装有64支枪；
- 建设期为3年。
目前还没有类似船只的类似物。 但是，他本人也没有持续很长时间，在庆祝其建造过程中沉没了。
当他们试图弄清楚为什么会发生这种情况时，发现与需求没有任何偏差。 大小相同，枪支数量正常，甲板上的水手正好是所需的数量。 然而，这与以下事实完美结合：物理定律不允许这种容器在水中停留任何时间。
亨利克（Henryk）的以下建筑失算是显而易见的（顺便说一句，如果他幸存于法院，这可能会使他丧命）：
- 所有冲突的限制都不平衡。
- 没有风险管理，因为以前没有人建造过这么大的船。
- 客户关系管理也缺席了-Henrik没有勇气与国王争论。
- 使用了错误的施工技术。
- 建筑师同意不可能的要求。
由于这些错误的计算，即使在设计阶段，该船也“坠落”。 这个故事很有启发性，因为它反映了架构周期对正在创建的应用程序的影响。 有利益相关方制定目标和要求，在此基础上，构建项目的体系结构，然后构建项目本身。 在这些阶段之一中犯错可能值得整个项目，有时甚至是负责任的工作，Henrik Hubertsson不会让你说谎。
强大的朋友
在编写第一行代码之前，有多少个具有错误体系结构的应用程序已死？
体系结构对项目的影响周期如下：
从左到右：
- 有利益相关方或利益相关者（就船舶而言，这就是国王和库房）。
- 他们有自己的目标（欧洲第一艘船）。
- 目标决定了要求（未来船的特定特性）。
- 接下来，绘制图纸，图表和设计。
- 在项目上施工。
这些阶段之一的错误可能会破坏项目的未来。
解决方案架构师手册
我们将考虑现实生活中的示例，并尝试从他人的错误中学习。 同时，我们将为解决方案架构师编写一本有用的建议书。 Henrik Hubertsson因为没有人而感到疲倦。
如果我们生活在自己的英雄时代，那么建筑错误可判处死刑，那么这本书将是鲜血写成的。
在所有故事中，都会给出建筑kata（任务）。 它们将包含一个简化的请求，其中包含客户的首要要求，问题的实质和结论。
吉米的发条故事
客户要求- 替换当前的UI解决方案。
- 为该解决方案的开发和实施引入一种新方法。
- 需要更好的用户体验。
- 同时，遵循所有最佳做法。
- 支持各种平台。
已经做了什么要求非常笼统，没有具体说明。 尚不清楚每个人都需要做什么。 同时，开发团队位于明斯克，客户位于蒙特利尔。 由于白俄罗斯和加拿大之间存在制裁，因此无法直接与加拿大进行合作。 决定通过都柏林的办事处与客户合作。 由于所有这些时间和调解上的延迟，因此无法联系客户并最终找到要求并提出实施建议。
一段时间后，某个Jimmy仍然开始回答问题并阐明要求，该项目的开发开始了。 吉米热切地分享建议，与他取得联系，并直接与他进行通信。 作为工作的结果，进行了介绍。 现在该显示结果了。 与来自客户的重要人员一起组织了一次会议，但是奇怪的是，吉米不在他们中间，没人知道那是谁。 当然，事实证明一切都与客户的期望完全不同。 事实是该公司对吉米一无所知，事实证明他是一名普通的开发人员，只是分享了他的经验和建议。 他没有做出决定，并且总体上来说，与该项目没有任何关系。
怎么了 在定义架构的最初阶段，利益相关者的定义不正确。
结论任何体系结构都始于确定利益相关者。 为了识别它们，有很多方法，我们将考虑其中一种-我们将建立一个RACI矩阵。
拉奇
缩写代表：R-负责任的人，将执行的人； A-负责任的决策者； C-咨询（商务人士）建议； 我-有见识的人，需要被告知的人。 每个相关方必须分配到一个或另一个类别。 该矩阵指示角色和任务。
建立了这样一个矩阵，我们可以了解谁是利益相关者。
此外，还注意到，在利益相关者中，有些人提出了虚假的主张而将项目搁置了。 在这种情况下，事实证明这些是其他对项目不感兴趣的供应商的代表。 但是RACI矩阵不知道如何区分此类客户，为此存在洋葱方法。
洋葱
洋葱方法与RACI矩阵有些不同。
其本质是在系统周围构建图层，并在其中指示某些客户的面孔。 在此示例中，开发人员，DevOps，内容管理员将与系统本身进行通信。 商务人士的抽象度更高。 也有外部监管者：媒体，法律等。 例如，要在某些国家/地区发布应用程序，您必须通过第三方公司的审核，这将揭示项目所需要的可访问性和其他质量，这些是外部利益相关者的要求。
因此，我们在架构师手册中写道，第一步是确定利益相关者的必要步骤。
历史：不够快
该公司有一个交易客户，在这件事上交易速度非常重要。 基于此，提出了许多要求。
客户要求做了什么该项目已完成，但失败了。 怎么了 同样，这些要求也不是完全正确的。 目标不是以0.5秒的速度进行交易，而是使其比竞争对手更快。 结果，速度达到了0.5秒，但当时的竞争对手达到了0.4秒。 我们在确定业务目标时发现错误。 客户为什么需要系统？
业务目标只是冰山一角，其背后是业务驱动力，监管者和公司的内部目标。 通常，它们仍然未知。 我们对技术目标（包括业务目标）更感兴趣。 它们受业务原则的约束，例如，没有人愿意在实现技术目标时牺牲工作质量，因为从长远来看，这是一种错误的估计。 在构建体系结构时，您需要了解并牢记所有这些。 以及没有目标的项目最初都死了的事实。
结论即使您在初创公司工作，其目的通常是测试新技术，但无论如何在项目中使用新技术都不是业务目标。 问题在于，如果目标是使用新技术，则该项目将不断增长，并需要新的不必要的财务和临时投资。 在设计体系结构时，业务目标不应被忽略。
您可以在作者“发现需求”一书中找到有用的建议-Ian Alexander，Ljerka Beus-Dukic。
马匹先驱者如何挤奶的故事
一家销售保险的公司拥有自己的网站。 它的效果很好，并且具有良好的既定功能。 它已经具有复杂的业务逻辑。
客户要求- 除了该站点之外，您还需要制作一个员工可以在其手机上使用的移动应用程序
- 该应用程序必须具有离线模式。
做了什么根据需求，决定使用React Native进行编写。 开发已经开始。 在第一个电话中，收到了对要求的改进和补充：
- 该公司向员工发布电话，并且它们都可以在Android上使用。
- 客户仅对离线模式感兴趣。
- 截止日期-两个月。
显然，挑选具有复杂业务逻辑的现成第三方产品并在两个月内编写一个新产品的任务不适合这样的时间范围。 决定使用PWA（渐进式Web应用程序）。
我已经有过这样的工作经验。 不仅编写了PWA应用程序，而且是同构的。 客户端服务器上的服务被重用，编写了特殊的包装程序，您可以与这些服务进行通信。 编写了一个路由器，将所有请求重定向到MongoDB数据库；在客户端上，通过适配器，它们与IndexedDB一起使用。 方案如下。
因此，问题出在需求上，而不是那么简单。 考虑一个要求的示例：
有一个表格，我们需要产生验证错误，如果输入了错误的URL，则需要显示页面404。要求有什么问题？ 他们谈论系统应该做什么。 但是对于架构师来说，什么系统应该更重要。 如果您深入研究系统应该做什么，您可能会深入细节并走错方向。 这样的需求称为功能需求，也称为MoSCoW需求。 这些要求中经常出现的词：
包含这些词的所有要求都不会让您感兴趣。 如果您专注于此类需求，那么将构建完全没有任何特殊架构的单片系统。
结论架构师应专注于非功能性需求，尤其是限制和质量属性。 关于这个的下个kata。
白乌鸦的故事
客户要求- 开发一个单独的服务，以xml格式转换和缓存数据。
- 他必须从第三方旧式系统执行此操作。
做了什么我们开发了一个很好的工作服务，它是在Node.js上完成的。 这就是系统作为整体与引入的新服务一起外观示意图的方式。
显然，尽管一切运行良好，但Node.js实在是令人沮丧。
该错误是在将服务转移给不熟悉Node.js的客户的过程中发现的。 这种情况很好地显示了确定项目约束的作用。 有什么限制？
结论建筑师有义务找出可能影响最终产品的所有现有限制。 局限性是您之前和为您做出的体系结构决策。
接下来，我们转向质量属性，我们对它们特别感兴趣。
质量属性
非常安全的图书馆
质量属性很多，您只需要查看Wikipedia提供给我们的列表即可。
故事基于“安全”属性。 当您访问图书馆时，您几乎不会期望在那里使用一台计算机通过输入电子邮件，电话和电话中的验证码来进行两要素授权。 然而，这确实发生了。 我们看到质量属性的盲目应用也可能会引起麻烦。
在森林里的电话
性能如何？ 显然，没有人不关心绩效。 这是脚本。 假设某人想在森林中使用手机上的移动应用程序。 因此，它影响我们的系统，但不影响整个系统，而是影响Web界面。 例如，他需要在三秒钟内获取一些数据。 这是我们应该获得的性能方案。
这类用例是架构师必须收集的，以便在输出端构建高质量的系统。 当我们有了业务需求，质量属性，约束条件的列表时，我们认识到所有利益相关者，便开始在图表中解决它们。 图上的属性寻址称为架构策略。 可以根据现有方案将哪些架构策略应用于森林中的电话系统？
- 改进UX，以使人看起来生产率更高。
- 优化资源（JS，CSS，图像，字体等）。
- 执行缓存。
- 添加服务人员，关键路径。
- 应用压缩。
- HTTP / 2。
但是，对于森林中的电话，UX和关键路径并不立即适合我们。 同样，战术应由脚本决定。 这是架构师的工作，可以从特定情况下的所有必要策略中进行选择。 但是，应用程序不仅是前端。 DNS，后端，数据库也会影响性能，所有这些都可以得到优化。 如何执行此操作有许多策略，但是，再次应用，则取决于使用情况。
让我们尝试使用CQRS（命令查询责任分离）模式。 使用这种模式作为策略甚至会影响应用程序的多个层：后端和前端。
假设有一个非常慢的旧数据库，我们在那里发送请求，十秒钟后我们得到响应。 此外，它已被复制，您需要在两个副本中都进行输入。 我们在电话里的森林中希望从该数据库中快速读取我们的数据。 该模式表示，我们应该分开读取和写入请求。 添加一个快速读取的数据库。 我们将添加所有使该数据库与现有数据库同步的方法。
这些要求应该非常清楚地说明使用这种繁琐的策略。
因此，我们使用了一些策略。 我们启动了该应用程序，发现它没有帮助，因为没有Internet连接。 因此，我们得出了解决方案架构师应注意的容错能力。
坚定的锡兵
没有人希望应用程序每天稳定下降几次，每个人都希望容错。
为了使应用程序稳定运行，可以应用快速失败原理：
为什么使用它，让我们看一下Lie Connection的示例。 这可能是ping的连接，但实际上不起作用。 这可能在客户端和服务器之间，数据库和服务器之间，服务之间发生。 将断路器模式应用于它。
尽管一切顺利，但是我们什么也没做。 一旦超过超时时间，我们就会离线，并在一段时间后发出新请求。 如果再次发生错误请求，我们将继续处于离线模式，超时时间会增加。 如果请求顺利，我们将返回在线模式。 因此，这种模式可以验证积分点，并避免连接缓慢。
潜艇
提供容错的方法很多。 其中之一是舱壁（例如，潜艇中的舱壁）。 其含义是，即使应用程序的其中一个组件出现错误，应用程序也可以继续工作。
我们有一个业务逻辑，可以在其中发送数据并接收响应。 我们开始用我们的策略来构架它，添加验证和扩展。 业务逻辑中发生错误。 我们记录下来。 作为错误信息，我们需要它发生的上下文。 麻烦的是，使用这样的逻辑框架，上下文不可能持久，因此，我们需要进行内存转储。 内存转储是相当大的事情，并且JavaScript错误很少发生，因此，这是一种计算资源非常昂贵的策略。 我们需要将错误分为严重错误而不是严重错误，并且仅针对第一个错误进行转储。
漏斗
在“漏桶”模式中使用了与上述类似的策略。
我们有针对不同类型错误的计数器。 当发生错误时，此类型的错误计数器将增加。 通过超时，此计数器减少。 但是，如果错误数量开始超出范围，则计数器没有时间减少，并且比喻地讲，桶溢出了，之后我们进行了内存转储。 接下来，我们处理导致计数器溢出的错误。
请注意，实现此模式的服务也将包含在策略，验证中并进行扩展。 这样就建立了架构。
绿色箭头是什么意思？ 不同的服务通过各种协议，数据库和其他服务相互交互。
, , «Patterns for fault tolerant software», — Robert S. Hanmer.
«Software Architecture in Practice», — Len Bass, Paul Clements, Rick Kazman. .
, :
. .
— .
- — ( ).
: , -.
:
- Drupal, - .
- ReactJS VueJS, , , .
quality-, :
- 400 (maintainability).
- , (testability).
- (re-usability).
- (performance).
- (accessibility).
, . C4. .
:
, . , -.
:
-, -, . , - -. .
:
, , Template Service, . - . , , , -.
-? - . , Template Service. , Drupal -. , NuxtJS Next.js, , , Vue.js React.js. GitHub , , JAM-. JavaScript, API, Markdown.
, , , . Node.js - . Drupal -, , CMS, , , . Javascript, API, Markdown .
结论. .
, , , . . , .
?
, , , . -, .
结论, , .
总结
, . . , , , :
- (stakeholders).
- - .
- , . , .
- .
- .
- , .
, : 24-25 HolyJS , . — , .