NotionNext BLOG slw.ac.cn/ 这是一个由NotionNext生成的站点 Tue, 24 Oct 2023 12:52:50 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2023, 蓑笠翁 <![CDATA[【读书笔记】《Go With The Domain》1. 准备项目案例]]> slw.ac.cn/article/go-with-the-domain-1.html slw.ac.cn/article/go-with-the-domain-1.html Wed, 04 Oct 2023 00:00:00 GMT
该电子书通过实际案例的方式，介绍了在项目中如何使用DDD和CQRS实践整洁架构，并对一些常见反模式的设计提出了改进方法，最终完成一个用 Go 构建的面向业务的应用程序框架。
本书的想法是不要过多关注基础设施和实现细节，但我们需要有一些基础，以便以后可以在此基础上进行构建。在介绍具体的方法之前，需要先设计一个便于举例的模拟项目，本文就是介绍该模拟项目的框架和背景。

基础设施：使用GoogleCloud托管K8S集群

考虑到使用自建K8S集群部署需要一个专门的DevOps团队，成本较高，因此采用托管K8S集群到的方式更加灵活方便， 你只需要提供容器镜像即可。在此容器内，您可以运行用任何语言编写的应用程序，该应用程序可以使用 HTTP 或 gRPC API 公开端口。也可以在此容器内处理 Pub/Sub 消息。这就是您在基础设施方面所需要的一切。本书创建了一个功能齐全、真实的应用程序，使用 Terraform 通过一条命令将此应用程序部署到 Google Cloud。
当然，也可以通过docker-compose将应用部署到本地。

基础设施：本地运行

对于由数百个微服务构建的项目来说，实现这一目标要困难得多。幸运的是，我们的项目只有 5 个服务。在 Wild Workouts 中，我们创建了 Docker Compose，并为前端和后端重新加载了实时代码。
  • 对于前端，我们使用带有 vue-cli-service 服务工具的容器。
  • 对于后端来说，情况稍微复杂一些。在所有容器中，我们运行reflex工具。 reflex 侦听任何触发服务重新编译的代码更改。

运行

  1. 安装docker和docker-compose
  1. 下载代码：git clone https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example.git && cd wild-workouts-go-ddd-example
  1. 运行：docker-compose up
  1. 访问： http://localhost:8080/。 这里官方也部署了一个可以公开访问的示例，可以直接访问： https://threedotslabs-wildworkouts.web.app

示例项目Wild Workouts是做什么的

很多Go教程中的模式在实际项目中不起作用的情况有多少？可能太频繁了。现实生活并不像教程中那么简单。为了避免这个问题，我们创建了 Wild Workouts 应用程序作为一个功能齐全的项目。只有一开始花足够的时间，才能在后期的实施过程中节省更多的时间。
闲话少说，进入正题。Wild Workouts 是一款面向私人健身教练和参与者的应用程序。
  • 教练可以在他们有空的时间段制定培训时间表
  • 学员可以安排指定日期的培训。
  • 其他功能包括：
    • “积分”管理（学员可以安排多少次培训）
    • 取消 – 如果培训在开始前 24 小时内取消，学员将不会收到返还的积分
    • 培训重新安排
      • 如果有人想要在培训开始前 24 小时内重新安排培训，则需要得到第二位参与者（教练或学员）的批准
    • 日历视图
教练设置时间表
教练设置时间表
学员选择健身的时间
学员选择健身的时间

前端技术

前端和项目设计关系不大，不需要特变关注，这里用到的前端技术有：
  • OpenAPI (Swagger) client。生成后端接口的说明文档的工具，方便JavaScript访问
  • Bootstrap。前端资源打包工具，创建HTML等
  • Vue.js。前端开发框架

后端服务

  1. trainer服务。管理教练的时间表，提供公开的HTTP接口，和内部gRPC接口
  1. trainings服务。管理学员的培训。提供公开的HTTP接口
  1. users服务。管理积分和用户信息

公开HTTP接口

应用程序执行的大多数操作都是由 HTTP API 触发的。我多次听到 Go 新手问他们应该使用什么框架来创建 HTTP 服务。我始终建议不要在 Go 中使用任何类型的 HTTP 框架。一个简单的路由器，比如 chi15 就足够了。 chi 只为我们提供了轻量级的粘合剂来定义我们的 API 支持哪些 URL 和方法。在底层，它使用 Go 标准库 http 包，因此所有相关工具（如中间件）都是 100% 兼容的。在 Go 中使用任何类型的框架都会增加不必要的复杂性，并将您的项目与该框架耦合在一起，这里需要遵循KISS原则（Keep It Simple And Stupid）。所有服务都以相同的方式运行 HTTP 服务器。
注：这里我们使用gin框架也是没有问题的。
然后在trainings服务中启动：
RunHTTPServer的入参是createHandler函数，createHandler需要返回http.Handler。在我们的例子中，它是由 oapi-codegen 生成的 HandlerFromMux (在openapi_api.gen.go)。它为我们提供了 OpenAPI 规范中的所有路径和查询参数
接口定义在trainings.yml：
如果需要修改接口，需要重新生成GO和JavaScript客户端的代码，已经封装在make命令中： make openapi。
工具不仅生成路由，还生成了业务功能接口：
下面是实现该接口的例子：
HTTP 路径并不是 OpenAPI 规范生成的唯一内容。更重要的是，它还为我们提供了响应和请求的模型。在大多数情况下，模型比 API 路径和方法复杂得多。生成它们可以在任何 API 合同更改期间节省时间、解决问题并减少挫败感。
举例，定义的数据（trainings.yml）如下：
生成的结构体如下：

云数据库Firestore

如果我们想以最现代、可扩展且真正无服务器的方式构建应用程序，Firestore 是一个自然的选择。我们将开箱即用。他的限制是1 update / second / one document. 但对于独立的文档是并行处理的，实际使用时问题不大。

在本地运行 Firestore

不幸的是 Firestore 模拟器并不完美。我发现有些情况下模拟器与真实版本不100%兼容。我也遇到过一些情况，当我在事务中更新和读取同一个文档时，它导致了死锁。在我看来，这个功能对于本地开发来说已经足够了。另一种选择可能是拥有一个单独的 Google Cloud 项目来进行本地开发。我在这里的偏好是拥有一个真正本地的本地环境，并且不依赖于任何外部服务。它也更容易设置，并且可以在以后的持续集成中使用。自 5 月底以来，Firestore 模拟器提供了 UI。它已添加到 Docker Compose 中，并可从 http://localhost:4000/ 获取。

使用Firestore

除了 Firestore 实现之外，代码在本地和生产环境中的工作方式相同。当我们在本地使用模拟器时，我们需要在.env文件中将 env FIRESTORE_EMULATOR_HOST 设置为模拟器（firestore:8787）来运行我们的应用程序
使用firestore：
读出来的数据都是map[string]interface，再转换为需要的数据格式

生产环境部署

再输入一些项目信息和账户信息就可以部署了。
 
 
 
 
 
 
 
 
 
《Go With The Domain》电子书下载：
 
]]> <![CDATA[【读书笔记】《Go With The Domain》14. 战略 DDD 简介]]> slw.ac.cn/article/go-with-the-domain-14.html slw.ac.cn/article/go-with-the-domain-14.html Wed, 04 Oct 2023 00:00:00 GMT
几年前，我在一家 SaaS 公司工作，该公司可能遇到了所有可能的软件开发问题。代码非常复杂，添加简单的更改可能需要几个月的时间。项目的所有任务和范围均由项目经理单独定义。开发人员不明白他们要解决什么问题。如果不了解客户的期望，许多实现的功能都是无用的。开发团队也无法提出更好的解决方案。
尽管我们有微服务，但引入一项更改通常需要对大多数服务进行更改。该架构耦合如此紧密，以至于我们无法独立部署这些“微服务”。业务人员不明白为什么添加“一个按钮”可能需要两个月的时间。最终，利益相关者不再信任开发团队。我们都很沮丧。但情况并非毫无希望。
我很幸运能够对领域驱动设计有所了解。那时我还远远不是那个领域的专家。但我的知识足够扎实，可以帮助公司最大限度地减少甚至消除所提到的大部分问题。
一段时间过去了，这些问题在其他公司并没有消失。即使这些问题的解决方案存在并且不是神秘的知识。人们似乎并没有意识到这一点。也许是因为 GRASP (1997)、SOLID (2000) 或 DDD（领域驱动设计）(2003) 等旧技术经常被遗忘或被认为已经过时？这让我想起了历史上黑暗时代发生的情况，当时古老的知识被遗忘了。同样，我们可以使用旧的想法。它们仍然有效并且可以解决当今的问题，但它们经常被忽视。这就像我们生活在软件的黑暗时代。
另一个相似之处是关注错误的事情。在历史上的黑暗时代，宗教压制了科学。在软件黑暗时代，基础设施正在淘汰重要的软件设计技术。我并不是说宗教不重要。精神生活非常重要，但如果你正遭受饥饿和疾病的折磨，那就不那么重要了。基础设施也是如此。如果您的软件设计很糟糕，那么拥有出色的 Kubernetes 集群和最精美的微服务基础设施对您也无济于事。

软件黑暗时代是一个系统问题

软件黑暗时代是一个非常强大的自我延续系统。如果不了解大局，就无法解决系统性问题。系统思维是一种有助于分析此类复杂问题的技术。我使用这种技术来可视化软件黑暗时代。
你可以看到事物相互加速的一个大循环。如果不干预，问题就会变得越来越大。领域驱动设计如何解决这个问题？
与大多数著名的编程大师不同，我们不希望您只相信我们的故事。我们可以弥补一下。幸运的是，我们可以用科学来解释它为什么有效。更准确地说，是基于科学研究的优秀《加速：精益软件科学和 DevOps（Accelerate: The Science of Lean Software and DevOps）》一书。书中描述的研究提到了表现最好和最差团队的特征。最关键的因素之一是松散耦合的架构。
如果您认为微服务可以为您提供松散耦合的架构，那您就大错特错了。我多次见过比单体架构耦合程度更高的微服务。这就是为什么我们需要的不仅仅是基础设施解决方案。这就是领域驱动设计（DDD）发挥作用的时候了。
这一关键的架构属性使团队能够轻松测试和部署单个组件或服务，即使组织及其运营的系统数量不断增长，也就是说，它允许组织随着规模的扩大而提高生产力。
(...) 如果忽略这些特征，那么采用部署在容器上的最新的精妙微服务架构并不能保证更高的性能。
(…) 支持此策略的架构方法包括使用有界上下文和 API 作为将大型域解耦为更小、更松散耦合的单元的方法，以及使用测试替身和虚拟化作为隔离测试服务或组件的方法。
()

DDD 不起作用

也许您知道有人尝试过 DDD，但它对他们不起作用？也许你和一个不太理解它的人一起工作，试图强行使用这些技术，并使一切变得太复杂？
也许你在 Twitter 上看到过一些著名的软件工程师说 DDD 不起作用？也许对你来说，这是一个传说中的圣杯，有人声称为他们工作——但还没人见过它。
我们不要忘记，我们生活在软件的黑暗时代。上一个时代的想法有一个问题——有些人可能会错过 DDD 的最初点。在 2003 年首次提出 DDD 的背景下，这并不奇怪。
进入 DDD 世界并不容易。许多书籍和文章由于过度简化而忽略了最重要的 DDD 要点。它们也经常用脱离现实的抽象例子来解释。太长、太复杂、难以理解的例子也并不罕见。让我尝试用最简单的方式解释 DDD。

从黑暗时代到文艺复兴

DDD 技术可以分为两个部分。战术和战略模式。战术领域驱动设计模式是关于如何在代码中实现解决方案。战术 DDD 中没有复杂的技术——它完全是关于面向对象编程的良好实践。但在编写代码之前，您需要知道要实现什么。这就是战略 DDD 模式发挥作用的地方。
许多描述 DDD 的资料来源大部分时间都在讨论战术模式。有时，他们甚至会跳过战略模式。您可以仅使用战略模式来练习 DDD。在某些项目中，使用战术 DDD 模式甚至是大材小用。不幸的是，大多数人正在做完全相反的事情。他们只使用战术模式，而不使用战略部分。这太可怕了。
如果有人问我产品软件工程中是否存在灵丹妙药(银弹)，我只会说一个候选者：领域驱动设计战略模式。战略 DDD 帮助我们得到以下问题的答案：
  • 您正在解决什么问题？
  • 您的解决方案能否满足利益相关者和用户的期望？
  • 该项目有多复杂？
  • 哪些功能不是必需的？
  • 如何分离服务以支持长期快速发展？在实施新项目、添加新功能或进行重构时
这些问题至关重要。战略 DDD 模式为我们提供了一种一致且可预测地回答这些问题的方法。一些工程师告诉我他们“只是工程师”。他们不太关心谁使用他们的软件或为什么使用他们的软件。例如，他们只是实现 JIRA 任务——构建在输入上有一些字节、在输出上有一些字节的服务。这种心态会导致工程师和客户之间的巨大脱节，而我们作为工程师正在努力解决客户的问题。如果没有适当的沟通，就很难创建以正确的方式帮助客户的解决方案。这就是最终的目标——不仅仅是处理字节。
在项目的规划阶段花费少量时间是很诱人的。尽快开始编码并尽早完成。当有人有这样的疑问时，我想说“用 5 天的编码时间，可以节省 1 天的计划时间”。未提出的问题不会神奇地消失。
克服软件黑暗时代的最佳方法是从多个角度对其进行攻击。让我们看看 DDD 模式如何攻击系统。

事件风暴

事件风暴是战略 DDD 模式和一般软件开发的游戏规则改变者。我无法相信为什么它还没有被世界上的每个团队采用。事件风暴是一个研讨会，在此期间有问题的人（通常是开发人员）与有答案的人（通常是利益相关者）会面。在会议期间，他们可以快速探索复杂的业务领域。一开始，您专注于构建基于领域事件（橙色便签）的完整工作流程。事件风暴是一种超级灵活的方法。因此，您可以验证您的解决方案是否满足预期要求。您还可以根据会话的目标探索数据流、潜在问题或用户体验。
验证解决方案是否没有缺陷以及是否符合用户的要求需要几分钟的时间。在开发和部署的代码中引入更改和验证想法的成本要高得多。但是更换黑板上的便利贴成本非常低。
土木工程师或火箭工程师可以很快看到错误的结果。他们在完成构建过程之前就可以看到明显存在问题。对于软件来说就不那么简单了，因为它不容易被看到。我们的大多数关键决定不会伤害任何人。功能开发和维护的问题不会一天出现。
当您计划一个大项目或只是一个故事时，事件风暴很有效。这只是您愿意花多少时间的问题。当我们将它用于一个故事时，它可能会持续 10 分钟到几个小时。我们倾向于花费一天到几天的时间来获得更大的功能。课程结束后，您应该得到以下问题的正确答案：
  • 您试图解决什么问题 – 而不是猜测什么可能对最终用户有用或假设“我们更了解一切”
  • 利益相关者是否对提议的解决方案感到满意 – 而不是半年后验证这一点实施过程中
  • 问题的复杂性显而易见 – 清楚地说明了为什么添加一个按钮可能需要大量工作
  • 如何按职责拆分微服务的初步想法 – 而不是盲目地将“类似事物”分组
最终，您将获得利益相关者更多的信任，因为您正在共同规划解决方案。这是比在地下室进行隔离编码更好的方法。事件风暴的优点在于，正确完成的会话的结果可以直接映射到代码。它应该可以帮助您在开发过程中避免许多讨论并大大加快您的工作速度。
notion image
你必须从一个明确的目标开始。一个项目的时间过得很快，不知不觉中，你在一个项目上花了半年时间，却发现它对任何人都没有用。你有过这样的经历吗？这种情况发生的频率比您想象的要高，这就是为什么有些人对“工程师”失去信任，以及我们最终成为没有任何自主权的开发人员的原因。
人们普遍担心我们需要“损失”多少时间来进行会话。考虑会话过程中损失的时间并不是正确的方法。相反，您应该考虑如果不进行该会话您将失去的好处。我在运行一次事件风暴会议时听到了这个故事，导致该项目的实施停止了几个月。这听起来可能很糟糕，但在会议期间，团队发现当前的假设完全无效。该项目的继续将导致彻底失败。即使该会议在短期内看起来很耗时，该公司也避免了几个月无用的开发。

事件建模

2018 年，Adam Dymitruk 提出了事件建模技术。该想法在很大程度上基于事件风暴技术，但添加了一些新功能。它还特别强调了会议的用户体验部分。一般来说，这些技术非常兼容。即使您继续使用事件风暴，您也可能会从事件建模中找到一些可以使用的有价值的方法。您可以在 eventmodeling.org 上阅读有关该技术的更多信息。
notion image

界限上下文和事务边界（聚合）

有界上下文是另一种战略 DDD 模式，可以帮助我们将大模型分割成更小的逻辑部分。
这是实现适当的服务分离的关键。如果您需要接触系统的一半来实现和测试新功能，那么您的分离是错误的。
除了错误的分离之外，还有缺乏分离。通常，缺乏分离的症状是神物体（知道太多或做太多的巨大物体）。在这种情况下，更改将主要影响一项服务。这种方法的成本是更大的系统故障风险和更高的变更复杂性。
换句话说，在这两种情况下，开发项目都会变得更加困难。
帮助发现界限上下文和聚合的一个很棒的工具当然是事件风暴。会议的结果是，您可以直观地了解应如何在服务和接触点之间划分服务和接触点。
notion image

通用语言

通用语言是一种战略 DDD 模式，涵盖在开发人员、运营、利益相关者和用户之间建立通用语言。这是最被低估的战略 DDD 模式。因为谁关心语言，对吧？
我花了一些时间才发现开发人员和非开发人员之间有多少沟通问题是因为使用不同的语言而造成的。这是多么痛苦啊。我鼓励你也关注这一点。由于沟通不畅，开发人员无法解决正确的问题，因为没有人了解对他们的期望。
如果我告诉您事件风暴将帮助您开发通用语言，您会感到惊讶吗？与利益相关者一起举办会议迫使您与他们交谈。当你们无法互相理解时，就很难共同制定解决方案。这就是为什么不要错过研讨会上的利益相关者至关重要！

DDD 能解决所有问题吗？

即使 DDD 很棒，它也不能解决我们遇到的所有问题。管理你的期望很重要。即使我们在我的团队中高水平地使用这些技术，我们仍然怀疑创建的设计是否足够好。有时我们不知道如何解决问题。有时我们会从代码回到设计阶段。有时我们会做出错误的决定。所有这些都是非常好的情况。世界上没有一支球队不存在这些问题。最好假设它会发生并且不要感到惊讶。但我们知道，如果没有 DDD，这些问题将会更加严重。
在使用 DDD 时，您应该特别注意避免：
  • 预先进行大设计
  • 实现“面向未来”的代码
  • 尝试创建完美的东西
相反，您应该：
  • 专注于以一种快速的方式将 MVP 交付给用户时间很短（我的意思是1个月而不是6个月）
  • 如果你需要“为了未来”实现一些东西，因为以后添加它会更困难，这是一个非常糟糕的迹象。您应该考虑如何方便以后添加它
  • 即使你尽了最大努力，你的设计也不会从一开始就完美——随着时间的推移改进它会更好。
对于一些团队来说，可能需要做很多工作才能达到这个水平。但根据我的经验，我可以向你保证这是可能的。再次交付软件所带来的乐趣是值得的！
💡
注意 如果您认为自己应该成为技术领导者来提出此类改进建议，那您就错了！早期，当我还不是领导者时，我已经向我工作的团队提出了许多改进建议。你需要与你的队友进行良好的争论。 我们总是在章节中解释这些技术“为什么”有效。当你使用这些论点时，它们应该足以说服他们。如果因为你的团队思想封闭而行不通，那么这就是考虑换工作的充分理由。

软件复兴

很难在一章内深入介绍所介绍的技术。我的目标是激励你质疑现状。这不是我们的行业应该如何运作的。如果您对现状不满意，我希望我能激励您学习新技术。这是对抗软件黑暗时代的最佳方式。
战略 DDD 模式怎么样？本章实际上是对我们的章节系列的下一部分的介绍。在接下来的几个月中，我们将在一个完整的示例项目中深入介绍最重要的战略 DDD 模式。
在软件黑暗时代，你是谁？
只是一个盲目遵守别人强加的规则的普通乡巴佬？
宗教裁判所，谁会试图去憎恨和扼杀任何不寻常的做法？
炼金术士，想炼金子？
即使没有科学依据？或者也许您正在地窖里偷偷地阅读禁书？
也许您正在寻求与我们一起结束软件黑暗时代并开始软件复兴？
]]> <![CDATA[【读书笔记】《Go With The Domain》13. 在 CI/CD 管道中运行集成测试]]> slw.ac.cn/article/go-with-the-domain-13.html slw.ac.cn/article/go-with-the-domain-13.html Wed, 04 Oct 2023 00:00:00 GMT
这篇文章是测试架构的直接后续内容，我在其中为我们的示例项目引入了新类型的测试。
Wild Workouts 使用 Google Cloud Build 作为 CI/CD 平台。它以持续部署的方式进行配置，这意味着一旦管道通过，更改就会立即投入生产。如果你考虑一下我们目前的设置，你会发现它既勇敢又天真。我们没有在那里运行可以避免明显错误的测试（无论如何，不太明显的错误很少能被测试发现）。
在本章中，我将展示如何使用 docker-compose 在 Google Cloud Build 上运行集成测试、组件测试和端到端测试。

当前配置

让我们看一下当前的cloudbuild.yaml 文件。虽然非常简单，但由于我们在单个存储库中保留 3 个微服务，因此大多数步骤都会运行多次。我专注于后端部分，所以我现在将跳过与前端部署相关的所有配置。
注意 waitFor 键。它使一个步骤需要等待其他指定的步骤完成。有些作业可以通过这种方式并行运行。这是更易读的版本：
notion image
我们对每项服务都有类似的工作流程：lint（静态分析）、构建 Docker 镜像并将其部署为一个或两个 Cloud Run 服务。
由于我们的测试套件已准备就绪并可在本地运行，因此我们需要弄清楚如何将其插入管道中。

Docker Compose

我们已经有了一个 docker-compose 定义，我想保持这种方式。我们将使用它来：
  • 本地运行应用程序
  • 本地运行测试
  • 在CI 中运行测试
这三个目标有不同的需求。例如，当本地运行应用程序时，我们希望进行代码热重载。但这在 CI 中毫无意义。另一方面，我们无法在 CI 中公开本地主机上的端口，这是在本地环境中访问应用程序的最简单方法。
幸运的是，docker-compose 足够灵活，可以支持所有这些用例。我们将使用一个基本的 docker-compose.yml文件和一个附加的 docker-compose.ci.yml 文件，其中仅覆盖 CI。您可以通过使用 -f 标志传递两个文件来运行它（请注意，每个文件都有一个标志）。文件中的密钥将按提供的顺序合并。
💡
注意 通常，docker-compose 会在当前目录或父目录中查找 docker-compose.yml 文件。使用-f标志禁用此行为，因此仅解析指定的文件。
要在 Cloud Build 上运行它，我们可以使用 docker/compose 镜像。
由于我们用正确的步骤名称填充了 waitFor，因此我们可以确保存在正确的镜像。这是我们刚刚添加的内容：
notion image
docker-compose.ci.yml 的第一个改造是使每个服务通过标签使用 docker 镜像，而不是从 docker/app/Dockerfile 构建镜像。这确保我们的测试检查我们要部署的相同镜像。
请注意图像键中的 ${PROJECT_ID} 变量，表示项目产品，因此我们不能将其硬编码到存储库中。 Cloud Build 在每个步骤中都提供了此变量，因此我们只需将其传递给 docker-compose up 命令（请参阅上面的定义）。

网络

如今，许多 CI 系统都使用 Docker，通常在具有所选镜像的容器内运行每个步骤。在 CI 中使用 docker-compose 有点棘手，因为它通常意味着从 Docker 容器内运行 Docker 容器。
在 Google Cloud Build 上，所有容器都位于 cloudbuild 网络内。只需将此网络添加为 docker-compose.ci.yml 的默认网络就足以让 CI 步骤连接到 docker-compose 服务。这是我们的第二个改造：

环境变量

使用环境变量作为配置乍一看似乎很简单，但考虑到我们需要处理多少场景，它很快就会变得复杂。让我们尝试列出所有这些：
  • 在本地运行应用程序
  • 在本地运行组件测试
  • 在 CI 中运行组件测试
  • 在本地运行端到端测试
  • 在 CI 中运行端到端测试
我没有在生产环境中运行该应用程序，因为它不使用 docker-compose。
为什么组件测试和端到端测试是不同的场景？前者按需启动服务，后者与 docker-compose 中已运行的服务进行通信。这意味着两种类型将使用不同的端点来访问服务。
💡
注意 有关组件和端到端测试的更多详细信息，请参阅测试架构。 TL;DR：我们重点关注组件测试，其中不包括外部服务。端到端测试只是为了确认合同没有在非常高的水平上被破坏，并且仅针对最关键的路径。这是服务解耦的关键。
我们已经保留了一个包含大多数变量的基本 .env 文件。它被传递给 docker-compose 定义中的每个服务。
此外，当 docker-compose 在工作目录中找到该文件时，它会自动加载该文件。因此，我们也可以使用 yaml 定义中的变量。
我们还需要在运行测试时加载这些变量。在 bash 中这很容易做到：
但是，.env 文件中的变量没有导出前缀，因此它们不会进一步传递到 shell 中运行的应用程序。我们不能使用前缀，因为它与 docker-compose 期望的语法不兼容。
此外，我们无法将单个文件用于所有场景。我们需要覆盖一些变量，就像我们对 docker-compose 定义所做的那样。我的想法是为每个场景保留一个附加文件。它将与基本 .env 文件一起加载。
让我们看看所有场景之间有什么区别。为了清楚起见，我只包含了 users-http，但这个想法将适用于所有服务。
notion image
docker-compose 运行的服务使用端口 3000+，组件测试在端口 5000+ 上启动服务。这样，两个实例就可以同时运行。
我创建了一个 bash 脚本来读取变量并运行测试。请不要尝试直接在 Makefile 中定义如此复杂的场景。Make 在管理环境变量方面很糟糕。
创建专用脚本的另一个原因是我们将 3 个服务保留在一个存储库中，并将端到端测试保留在一个单独的目录中。如果我需要多次运行相同的命令，我更喜欢调用带有两个变量的脚本，而不是使用长长的标志和参数。第三个原因是它们可以用 shellcheck 进行检查。
该脚本在给定目录中运行go test，并使用从 .env 和指定文件加载的环境变量。env / xargs 技巧将所有变量传递给以下命令。请注意我们如何使用 grep 从文件中删除注释。
💡
测试缓存 go test 会缓存成功的结果，只要不修改相关文件即可。在使用 Docker 的测试中，您可能会更改基础设施级别的某些内容，例如 docker-compose 定义或某些环境变量。 go test 不会检测到这一点，并且您可能会将缓存的测试误认为是成功的测试。 对此很容易感到困惑，而且由于我们的测试无论如何都很快，因此我们可以禁用缓存。 -count=1 标志是一种惯用的（尽管不明显）方法。

运行测试

在所有服务的测试通过后，开始运行端到端测试。它应该类似于您通常运行它们的方式。请记住，端到端测试应该起到双重检查的作用，并且每个服务自己的测试应该具有最大的覆盖范围。
由于我们的端到端测试范围很小，因此我们可以在部署服务之前运行它们。如果它们运行很长时间，这可能会阻止我们的部署。在这种情况下，更好的想法是依赖每个服务的组件测试同时并行运行端到端套件。
我们添加的最后一件事是在所有测试通过后运行 docker-compose。这只是一次清理。
我们管道的第二部分现在看起来像这样：
notion image
以下是本地运行测试的样子（我在上一章中介绍了此Make Target）。它与CI完全相同，只有不同的.env文件

分离测试

查看上一章中的表格，根据是否使用 Docker，我们可以将测试分为两组。
notion image
单元测试是唯一不使用 Docker 数据库的类别，而集成、组件和端到端测试则使用 Docker 数据库。
尽管我们使所有测试都变得快速且稳定，但设置 Docker 基础设施会增加一些开销。单独运行所有单元测试很有帮助，可以首先防止错误。
我们可以使用构建标签来分隔不使用 Docker 的测试。您可以在文件的第一行定义构建标签。
我们现在可以与所有测试分开运行单元测试。例如，下面的命令将仅运行需要 Docker 服务的测试：
最后，我决定不引入这种分离。我们使测试足够稳定和快速，因此一次运行所有测试并不是问题。然而，我们的项目非常小，测试套件只涵盖了关键路径。当它增长时，在组件测试中引入构建标签可能是个好主意。

题外话：一个关于 CI 调试的小故事

当我介绍本章的更改时，Cloud Build 上的初始测试运行一直失败。根据日志，测试无法从 docker-compose 访问服务。
因此，我开始调试并添加了一个简单的 bash 脚本，该脚本将通过 telnet 连接到服务。
令我惊讶的是，连接到 mysql:3306 工作正常，但 firestore:8787 没有，所有 Wild Workouts 服务也是如此。我认为这是因为 docker-compose 需要很长时间才能启动，但是多次重试都没有帮助。最后，我决定尝试一些疯狂的事情，我从 docker-compose 中的一个容器设置了一个反向 SSH 隧道。这允许我在构建仍在运行时在其中一个容器内进行 SSH。然后我尝试使用 telnet 和curl，它们对所有服务都能正常工作。
最后，我在我使用的 bash 脚本中发现了一个错误
变量定义中的拼写错误导致 telnet 命令运行变成了：telnet $host $host。那么为什么它对 MySQL 有效呢？事实证明，telnet 可以识别/etc/services 中定义的端口。因此 telnet mysql mysql 被转换为 telnet mysql 3306 并且工作正常，但对于任何其他服务都失败了。
为什么测试失败了？好吧，事实证明这是一个完全不同的原因。
最初，我们是这样连接MySQL的：
我查看了环境变量，所有这些都正确填写。添加一些 fmt.Println() 调试后，我发现配置的 Addr 部分被 MySQL 客户端完全忽略，因为我们没有指定 Net 字段。为什么它适用于本地测试？因为MySQL暴露在localhost上，这是默认地址。
另一个测试无法连接到 Wild Workouts 服务之一，结果是因为我在 .env 文件中使用了不正确的端口。
我为什么要分享这个？我认为这是一个很好的例子，展示了 CI 系统的工作方式。当多项事情都可能失败时，很容易得出错误的结论并在错误的方向上深入挖掘。
如有疑问，我喜欢使用基本工具来调查 Linux 问题，例如 strace、curl 或 telnet。这也是我使用反向 SSH 隧道的原因，我很高兴我这么做了，因为这似乎是调试 CI 内部问题的好方法。我觉得有时间我会再次使用它。

总结

我们设法保留一个 docker-compose 定义，用于在本地和管道中运行测试。从 git Push 到生产的整个 Cloud Build 运行需要 4 分钟。我们使用了一些巧妙的技巧，但这只是处理 CI 时的常规内容。有时你无法避免添加一些 bash 魔法来使事情正常进行。与领域代码相比，CI 设置中的黑客攻击不会对您造成太大伤害，只要其中只有少数。只要确保它很容易理解正在发生的事情，这样你就不是唯一拥有所有知识的人。
]]> <![CDATA[【读书笔记】《Go With The Domain》12. 存储库设计安全]]> slw.ac.cn/article/go-with-the-domain-12.html slw.ac.cn/article/go-with-the-domain-12.html Wed, 04 Oct 2023 00:00:00 GMT
通过测试和代码审查，您可以使您的项目没有错误。是吗？嗯……实际上，可能不是。那太简单了。这些技术降低了出现错误的可能性，但不能完全消除它们。但这是否意味着我们需要忍受错误的风险直到生命的尽头？
一年多前，我在Harbor项目中发现了一个非常有趣的 PR。这是对允许普通用户创建管理员用户这个问题的修复。这显然是一个严重的安全问题。当然，自动化测试之前并没有发现这个bug。错误修复如下所示：
一条 if 语句修复了该错误。添加新的测试还应该确保将来不会出现回归。够了吗？它是否可以保护应用程序在未来免受类似错误的影响？我很确定没有。
在更复杂的系统中，如果有一个大团队在处理这些系统，问题就会变得更大。如果有人是该项目的新手并且忘记添加此 if 语句怎么办？您可能会惊讶于您编写的代码的寿命有多长。我们不应该相信人们会按照预期的方式使用我们创建的代码——他们不会。
在某些情况下，能够保护我们免受此类问题影响的解决方案就是良好的设计。好的设计不应允许以无效的方式使用我们的代码。好的设计应该保证你可以毫无恐惧地接触现有的代码。新加入该项目的人会觉得引入变更更安全。
在本章中，我将展示如何确保只有允许的人才能查看和编辑训练。
在我们的例子中，只有训练所有者（学员）和教练才能看到训练。我将以一种不允许以非预期方式使用我们的代码的方式来实现它。通过设计。我们当前的应用程序假设访问数据的唯一方式是通过存储库。因此，我将在存储库添加授权级别。由此，我们确信未经授权的用户不可能访问这些数据。
💡
什么是存储库 tl;dr 如果您没有机会阅读我们前面的章节，那么存储库是一种帮助我们从应用程序逻辑中抽象数据库实现的模式。如果您想更多地了解它的优点并了解如何将其应用到您的项目中，请阅读存储库模式。
但是等等，存储库是管理授权的正确位置吗？嗯，我可以想象有些人可能会对这种方法持怀疑态度。当然，我们可以开始一些关于存储库中可以包含哪些内容和不应该包含哪些内容的哲学讨论。另外，谁可以看到训练的实际逻辑将被放置在领域层。我没有看到任何重大缺点，而且优点也很明显。在我看来，实用主义应该在这里获胜。
💡
提示 本书的另一个有趣之处是我们重点关注面向业务的应用程序。但即使 Harbor 项目是一个纯粹的系统应用程序，大多数提出的模式也可以应用。在向我们团队介绍 Clean Architecturea 后，我们的队友在他的游戏中使用了这种方法来抽象渲染引擎。

请告诉我代码！

为了实现我们的稳健设计，我们需要实现三件事：
  1. 谁能看到训练的逻辑（领域层）
  1. 用于获取训练的函数（存储库中的 GetTraining）
  1. 用于更新训练的函数（存储库中的UpdateTraining）

领域层

第一部分是负责决定某人是否可以看到训练的逻辑。因为它是领域逻辑的一部分（你可以和你的业务或产品团队讨论谁可以看到培训），所以它应该进入领域层。它是通过 CanUserSeeTraining 函数实现的。将其保留在存储库级别也是可以接受的，但很难重用。我不认为这种方法有任何优势——特别是如果将其放入领域不需要任何成本的话。

Repository

现在当我们有了 CanUserSeeTraining 函数后，我们需要使用这个函数。就这么简单。
是不是太简单了？我们的目标是创建简单而不复杂的设计和代码。这是一个很好的迹象，表明它非常简单。我们正在以同样的方式更改 UpdateTraining。
就这样！有什么办法可以让有人以错误的方式使用它吗？只要用户有效 – 就不会。这种方法类似于领域驱动设计精简版中介绍的方法。这一切都是为了创建我们不能以错误的方式使用的代码。这是 UpdateTraining 现在的用法：
当然，如果可以重新安排 Training，还需要设置其他一些规则，但同样也是由 Training 领域类型处理的

处理集合

即使这种方法非常适合单个训练的操作，您也需要确保对训练集合的访问得到适当的保护。这里没有魔法：
在应用程序层上执行 CanUserSeeTraining 函数将非常缓慢且代价大。最好创建一些重复的逻辑。
如果此逻辑在您的应用程序中更复杂，您可以尝试在领域层中将其抽象为可转换为数据库驱动程序中的查询参数的格式。我做过一次，效果非常好。
但在Wild Workouts中，它会增加不必要的复杂性 - 让我们保持简单。

处理内部更新

我们通常希望拥有允许开发人员或公司运营部门进行一些“后门”更改的端点。在这种情况下，你能做的最糟糕的事情就是创建任何类型的“假用户”和黑客攻击。
根据我的经验，它需要通过代码中的大量 if 语句来处理。它还会混淆审核日志（如果有的话）。与其创建“假用户”，不如创建一个特殊角色并显式定义该角色的权限。
如果您需要不用任何用户的存储库方法（对于 Pub/Sub 消息处理程序或迁移），最好创建单独的存储库方法。在这种情况下，命名至关重要——我们需要确保使用该方法的人知道安全隐患。
根据我的经验，如果不同参与者的更新变得非常不同，甚至值得为每个参与者引入单独的 CQRS 命令。在我们的例子中，它可能是 UpdateTrainingByOperations。

通过 context.Context 传递身份验证

据我所知，有些人通过 context.Context 传递身份验证详细信息。
我强烈建议不要通过 context.Context 传递应用程序正常工作所需的任何内容。原因很简单——当通过 context.Context 传递值时，我们失去了 Go 最重要的优势之一——静态类型。它还隐藏了函数的输入到底是什么。
如果您出于某种原因需要通过上下文传递值，这可能是您服务中某处设计不良的症状。也许该函数做了太多的事情，并且很难将所有参数传递到那里？也许是时候分解它了？
这就是今天的全部内容！如您所见，所提出的方法易于快速实施。希望对您的项目有所帮助，让您对未来的发展更有信心。
]]> <![CDATA[【读书笔记】《Go With The Domain》11. 测试架构]]> slw.ac.cn/article/go-with-the-domain-11.html slw.ac.cn/article/go-with-the-domain-11.html Wed, 04 Oct 2023 00:00:00 GMT
您是否知道当您从头开始开发新应用程序，并可以通过适当的测试覆盖所有流程时的罕见感觉？
我说“罕见”是因为大多数时候，您将使用历史悠久、贡献者众多且测试方法不那么明显的软件。即使代码使用了好的模式，测试套件也并不总是遵循。
有些项目没有设置现代化的开发环境，因此只有易于测试的东西才进行单元测试。例如，他们单独测试单个功能，因为很难测试公共 API。团队需要手动验证所有更改，可能是在某种临时环境中。您知道当有人引入更改但不知道他们需要手动测试时会发生什么。
其他项目从一开始就没有测试。它可以通过走捷径来加快开发速度，例如将依赖关系保持在全局状态。当团队意识到缺乏测试会导致错误并减慢它们的速度时，他们决定添加它们。但现在，想要合理地做到这一点是不可能的。因此，团队编写了一个具有适当基础设施的端到端测试套件。
端到端测试可能会给您一些信心，但您不想维护这样的测试套件。它很难调试，即使是最简单的更改也需要很长时间来测试，并且发布应用程序需要几个小时。在这种情况下引入新的测试也不是小事，因此开发人员尽可能避免它。
我想介绍一些迄今为止对我们有用的想法，应该可以帮助您避免上述情况。
本章不是关于哪个测试库最好或者可以使用哪些技巧（尽管我将展示一些技巧）。它更接近我所说的“测试架构”。这不仅涉及“如何”，还涉及“在哪里”、“什么”和“为什么”。
关于不同类型的测试有很多讨论，例如“测试金字塔”（Robert 在高质量数据库集成测试中提到过）。这是一个值得记住的有用模型。然而，它也是抽象的，你无法轻易测量它。我想采取更实用的方法，展示如何在 Go 项目中引入几种测试。

为什么要为测试烦恼呢？

但是测试代码难道不像应用程序的其余部分那么重要吗？难道我们不能接受保持测试良好状态是困难的事实并继续前进吗？不是可以加快开发速度吗？
如果您一直关注本系列，您就会知道我们的所有章节都基于 Wild Workouts 应用程序。
当我开始编写本章时，本地运行测试对我来说甚至无法正常工作，而且这是一个相对较新的项目。
发生这种情况的原因之一是：我们没有在 CI 管道中运行测试。
这令人震惊，但似乎即使是使用最流行、最前沿技术的无服务器、云原生应用程序也可能是混乱中伪装出来的。
我们知道现在应该向管道添加测试。众所周知，这让您有信心将更改安全地部署到生产中。然而，这也是有代价的。
运行测试可能会占用管道持续时间的很大一部分。如果您没有以与应用程序代码相同的质量来设计和实现它们，您可能会意识到得太晚了，管道需要一小时才能通过，并且会随机失败。即使您的应用程序代码设计良好，测试也可能成为交付更改的瓶颈。

分层

我们对该项目进行了几次重构。我们引入了像 Repository这样的模式。通过关注点分离，我们可以更轻松地推理项目的特定部分。
让我们回顾一下在前面的章节中介绍过的分层的概念。如果您之前没有机会阅读这些内容，我建议您在继续之前阅读这些内容 - 这将帮助您更好地理解本章。看一下图表可以帮助我们理解项目的结构。以下是使用 Wild Workouts 中使用的方法构建的通用服务
整体框架
整体框架
所有外部输入都从左侧开始。应用程序的唯一入口点是通过端口层（HTTP 处理程序、Pub/Sub 消息处理程序）。端口在应用层执行相关处理程序。其中有些会调用Domain代码，有些会使用Adapter，这是退出服务的唯一途径。适配器层是数据库查询和 gRPC 客户端所在的位置。
下图显示了 Wild Workouts 中部分trainer服务的层次和流程。
trainer服务
trainer服务
现在让我们看看需要哪些类型的测试来涵盖所有内容。

单元测试

我们从内层和每个人都熟悉的东西开始：单元测试。
notion image
领域层是服务中最复杂的逻辑所在的地方。然而，这里的测试应该是一些最简单的编写和运行速度超快的测试。领域中没有外部依赖项，因此您不需要任何特殊的基础设施或模拟（除了非常复杂的场景，但我们暂时保留它）。
根据经验，您应该瞄准领域层的高测试覆盖率。确保仅测试导出的代码（黑盒测试）。将 _test 后缀添加到包名称中是强制执行此操作的一个很好的做法。
领域代码是纯逻辑且易于测试，因此它是检查所有极端情况的最佳位置。表驱动测试对此尤其有用。
我们离开领域，进入应用层。引入 CQRS 后，我们将其进一步分为命令和查询。
根据您的项目，可能不需要测试任何内容或需要涵盖一些复杂的场景。大多数时候，尤其是在查询中，此代码只是将其他层粘合在一起。测试这个不会增加任何价值。但如果命令中有任何复杂的编排，那么这就是单元测试的另一个好例子。
💡
注意应用程序层中的复杂逻辑。如果您在这里开始测试业务场景，那么值得考虑引入领域层。 另一方面，它是编排的完美场所——以特定顺序调用适配器和服务并传递返回值。如果程序像之前那样分层，那么每次更改领域代码时应用程序测试都不应该受影响。
与领域代码相反，应用程序的命令和查询中有许多外部依赖项。如果您遵循 Clean Architecture，那么很容易对他们进行mock。在大多数情况下，具有单个方法的结构可以实现完美的mock。
💡
注意：如果您更喜欢使用mocking库或由代码生成的mock代码，您也可以使用它们。 Go 允许您定义和实现小型接口，因此我们选择自己定义模拟，因为这是最简单的方法。
下面的代码片段展示了如何使用注入的mock创建应用程序命令。
请注意添加不检查任何相关内容的测试，这样您就不会最终测试模拟。如果没有业务逻辑，就完全跳过测试。我们已经覆盖了两个内层。我想到目前为止这似乎并不新鲜，因为我们都熟悉单元测试。然而，持续交付成熟度模型仅将它们列为“基本”成熟度级别。现在让我们看看集成测试。

集成测试

阅读此标题后，您是否想象过一个需要重试多次才能通过的长时间运行的测试？集成测试没有理由缓慢且不稳定。自动重试和增加睡眠时间等做法应该是绝对不可能的。
在我们的上下文中，集成测试是检查适配器是否与外部基础设施正常工作的测试。大多数时候，这意味着测试数据库存储库。
这些测试不是检查数据库是否正常工作，而是检查你是否正确使用它（集成部分）。这也是验证您是否知道如何使用数据库内部结构（例如处理事务）的绝佳方法。
notion image
因为我们需要真正的基础设施，所以集成测试的编写和维护比单元测试更具挑战性。通常，我们可以使用 docker-compose 来启动所有依赖项。
💡
注意：我们是否应该使用 Docker 版本的数据库来测试我们的应用程序？ Docker 镜像几乎总是与我们在生产环境中运行的镜像略有不同。在某些情况下，例如 Firestore，只有模拟器可用，而不是真正的数据库。 事实上，Docker 并不能反映您在生产环境中运行的确切基础设施。然而，你更有可能搞乱代码中的 SQL 查询，而不是因为细微的配置差异而偶然发现问题。 一个好的做法是将镜像版本固定为与在生产环境中运行的版本相同。使用 Docker 不会为您提供 100% 的生产同等性，但它消除了“在我的机器上运行”问题并使用适当的基础设施测试您的代码。 Robert 在高质量数据库集成测试中深入介绍了数据库的集成测试。

保持集成测试稳定和快速

当处理网络调用和数据库时，测试速度变得非常重要。并行运行测试至关重要，在 Go 中可以通过调用 t.Parallel() 启用并行测试。这看起来很简单，但我们必须确保我们的测试支持这种行为。
例如，考虑这个简单的测试场景：
  1. 检查数据库中trainings集合是否为空
  1. 调用添加训练的存储库方法
  1. 检查集合中是否有一项训练
如果另一个测试使用相同的集合，您将因竞争条件而随机失败。有时，该集合将包含多个我们刚刚添加的训练。
最简单的方法是永远不要断言列表长度之类的东西，而是检查它是否是我们正在测试的确切东西。例如，我们可以获取所有训练，然后迭代列表以检查是否存在预期的 ID。
另一种方法是以某种方式隔离测试，这样它们就不会互相干扰。例如，每个测试用例都可以在唯一用户的上下文中工作（请参阅下面的组件测试）。
当然，这两种模式都比简单的长度断言更复杂。当您第一次偶然发现这个问题时，可能很容易放弃并决定“我们的集成测试不需要并行运行”。不要这样做。有时你需要发挥创造力，但最终并不需要付出太多努力。作为回报，您的集成测试将稳定且运行得与单元测试一样快。
如果您在每次运行之前创建了一个新数据库，这也是可以保证测试不相互干扰。
💡
警告！在迭代测试用例时，有些常见但难以发现的问题。 在使用表驱动测试时，您经常会看到如下代码：
这是对一部分测试用例运行测试的惯用方法。假设您现在想要并行运行每个测试用例。解决方案看起来很简单：
遗憾的是，这不会按预期工作。 添加并行开关使父测试函数不再等待 t.Run 生成的子测试。因此，您无法在 func 闭包内安全地使用 c 循环变量。像这样运行测试通常会导致所有子测试都适用于最后一个测试用例，而忽略所有其他测试用例。 最糟糕的部分是测试将通过，并且在使用 -v 标志运行 go test 时您将看到正确的子测试名称。注意到这个问题的唯一方法是更改期望测试失败的代码并看到它们通过。正如 wiki 中提到的，解决此问题的一种方法是引入一个新的作用域变量：
这只是一个品味问题，但我们不喜欢这种方法，因为对于那些不知道这意味着什么的人来说，它看起来像是某种魔咒。相反，我们选择更冗长但明显的方法：
即使您了解这种行为，也很容易滥用它，非常危险。更糟糕的是，似乎流行的 linter 默认情况下不会检查这一点 - 如果您知道做得很好的 linter，请在评论中分享。我们在 Watermillb 库中犯了这个错误，导致一些测试根本无法运行。您可以在此提交中看到修复
我们通过测试覆盖了数据库存储库，但我们还有一个 gRPC 客户端适配器。我们应该如何测试这个呢？
在这方面它与应用层类似。如果您的测试会重复它检查的代码，那么添加它可能没有意义。更改代码时只会增加额外的工作。让我们考虑一下用户服务 gRPC 适配器：
这里没有什么有趣的东西可以测试。我们可以注入一个模拟客户端并检查是否调用了正确的方法。但这不会验证任何内容，并且代码中的每个更改都需要在测试中进行相应的更改。

组件测试

到目前为止，我们已经为应用程序的隔离部分创建了大部分狭窄的、专门的测试。此类测试非常适合检查极端情况和特定场景，但这并不意味着每个服务都能正常工作。很容易忘记从端口调用应用程序处理程序。此外，单独的单元测试并不能帮助我们确保应用程序在重大重构后仍然可以工作。
现在是对我们所有服务运行端到端测试的时候了吗？还没有。
由于没有调用测试类型的标准，我鼓励您遵循 Simon Stewart 的建议。创建一个表格，让团队中的每个人都清楚地了解特定测试的期望。然后，您可以删除有关该主题的所有（无成效的）讨论。在我们的例子中，该表可能如下所示：
notion image
为了确保每个服务在内部正常工作，我们引入了组件测试来检查所有层的协同工作。组件测试涵盖与应用程序中的其他服务隔离的单个服务。
我们将调用真正的端口处理程序并使用 Docker 提供的基础设施，还将模拟所有到达外部服务的适配器。
notion image
您可能想知道，为什么不测试外部服务呢？毕竟，我们可以使用 Docker 容器并一起测试它们。
问题在于测试多个连接服务的复杂性。如果你只有几个，那就足够了。但请记住，您需要为启动的每个服务配备适当的基础设施，包括它使用的所有数据库和它调用的所有外部服务。它很容易总共有数十个服务，通常由多个团队拥有。
我们将在接下来的端到端测试中讨论这个问题。但现在，我们添加组件测试，因为我们需要一种快速的方法来了解服务是否正常工作。
notion image
我们可以在不需要集成环境的情况下完成大部分测试。我们可以并且确实独立于它所依赖的其他应用程序/服务来部署或发布我们的应用程序。
等下，微服务不是应该解决团队相互依赖的问题吗？如果您认为在您所处理的应用程序中不可能实现这一目标，则可能是因为架构选择不佳。您可以通过应用我们计划在未来章节中介绍的战略 DDD 模式来修复它。 我们在本系列中提出了这一点：使用微服务并不会让您的应用程序和团队本身减少耦合。解耦需要对应用程序架构和系统级别进行有意识的设计。在组件测试中，我们的目标是单独检查单个服务及其所需的所有基础设施的完整性。我们确保服务接受我们同意的 API 并以预期结果进行响应。
这些测试在技术上更具挑战性，但仍然相对简单。我们不会运行真正的服务二进制文件，因为我们需要模拟一些依赖项。我们必须修改启动服务的方式才能使其成为可能。
💡
注意 再次强调，如果您遵循依赖倒置原则（只是提醒一下，它是 SOLID 的一部分），那么在服务级别注入模拟应该是微不足道的。
我为我们的 app.Application 结构引入了两个构造函数，它保存所有命令和查询。第一个的工作方式与以前一样，设置真正的 gRPC 客户端并注入它们。第二个用模拟代替它们。
我们现在可以简单地在单独的 goroutine 中运行该服务。
我们只想为所有测试运行一个服务实例，因此我们使用 TestMain 函数。这是在运行测试之前插入设置的简单方法。
我创建了 WaitForPort 辅助函数，该函数会等待指定端口打开或超时。这很重要，因为您需要确保服务已正确启动。不要用睡眠代替它。您要么添加太多的延迟，使测试变慢，要么让它太短，并且它会随机失败。
组件测试要测试什么？通常测试正常场景就足够了。不要检查那里的极端情况。单元和集成测试应该已经涵盖了这些。确保处理正确的有效负载、存储正常且响应正确。

调用端口

我使用 openapi-codegen 生成的 HTTP 客户端。与服务器部分类似，这使得编写测试变得更加容易。例如，您不需要指定整个 REST 路径，也不需要每次都序列化JSON。
尽管生成的客户端为我们节省了大量样板文件，但我仍然添加了带有客户端包装器的tests/client.go 文件以用于测试目的。
测试变得更具可读性，并且很容易理解发生了什么。让测试通过很容易，但在代码审查中理解它们、阅读所有断言和模拟要困难得多。
我们现在可以使用一行来清楚地说明正在发生的事情，而不是上面的代码片段。
其他辅助方法有 FakeAttendeeJWT 和 FakeTrainerJWT。他们使用所选角色生成有效的授权token。由于 gRPC 使用从 protobuf 生成的结构，因此客户端已经很容易使用。

端到端测试

最后，我们来到测试套件中最可怕的部分。我们现在将把所有模拟抛在脑后。
端到端测试验证您的整个系统协同工作。它们速度慢、容易出错并且难以维护。您仍然需要它们，但请确保将它们构建得很好。
在 Wild Workouts 中，它与运行组件测试类似，只是我们将启动 docker-compose 内的所有服务。然后，我们将验证一些仅调用 HTTP 端点的关键路径，因为这是我们向外部世界公开的内容。
💡
注意：如果您无法在 docker-compose 上运行整个平台，则需要找到类似的方法。如果您已经在使用它，它可能是一个单独的 Kubernetes 集群或命名空间，或者某种临时环境。
notion image
现在到了问题多于答案的部分。您应该在哪里进行端到端测试？哪个团队应该拥有它？在哪里运行它们？多频繁？它们应该是 CI/CD 管道的一部分还是从 cronjob 运行的单独的东西？
我无法给你明确的答案，因为这在很大程度上取决于你的团队结构、组织文化和 CI/CD 设置。与大多数挑战一样，尝试一种看起来最好的方法并迭代它，直到您满意为止。
我们很幸运，整个应用程序只有三个服务，所有服务都使用相同的数据库。随着服务和依赖项数量的增加，您的应用程序将变得更难以以这种方式进行测试。
尽量保持端到端测试简短。他们应该测试服务是否正确连接在一起，而不是测试它们内部的逻辑。这些测试起到双重检查的作用。大多数时候他们不应该失败，如果失败，通常意味着有人违反了合同。
💡
请注意，我说过我们将仅使用 HTTP 端点，因为这是公开公开的。有一个例外：我们通过 gRPC 调用用户服务来为测试参与者添加训练课时余额。正如您所期望的，公众无法访问此端点。
该代码与我们在组件测试中所做的非常接近。主要区别是我们不再在单独的 goroutine 中启动服务。相反，所有服务都使用我们在生产中部署的相同二进制文件在 docker-compose 内运行。

验收测试

您经常会发现验收测试被定义为单元测试和集成测试之后的下一个级别。我们认为它们与测试的技术方面是正交的。这是一个专注于完整业务功能而不是实现细节的测试。正如 Martin Fowler 所说：
事情是这样的：在某一时刻，您应该确保从用户的角度（而不仅仅是从技术角度）测试您的软件是否正常工作。你所说的这些测试实际上并不那么重要。然而，进行这些测试是：选择一个术语，坚持使用它，然后编写这些测试。
在我们的例子中，组件测试和端到端测试都可以被视为验收测试。如果您愿意，您可以对其中一些使用 BDD样式 - 这使它们更易于阅读，但添加了一些样板文件。
notion image

我们现在可以睡个好觉了吗？

除非我们在生产中破坏服务，否则它并没有真正经过测试。
可靠的测试套件将捕获大部分错误，以便您能够一致地交付。但无论如何，您都希望为停电做好准备。我们现在进入监控、可观测性和混沌工程的主题。不过，这不在今天的讨论范围之内。
请记住，没有任何测试套件可以给您完全的信心。拥有一个允许快速回滚、恢复和撤消迁移的简单流程也至关重要。

继续

如果您查看完整的 commit，您可能会注意到我们现在注入依赖项的方式不是很优雅。我们将在未来迭代这一点。我们已经有了测试套件，但我们仍然错过了一个关键部分：它没有在我们的持续集成管道中运行。此外，为测试提供适当的 docker-compose 和环境变量也并非易事。当前的解决方案有效，但如果您不知道发生了什么，则不容易理解。在自动化构建中运行测试只会使其变得更加复杂。我们将在以后的章节中介绍这些主题。
]]> <![CDATA[【读书笔记】《Go With The Domain》10. 结合 DDD、CQRS 和简洁架构]]> slw.ac.cn/article/go-with-the-domain-10.html slw.ac.cn/article/go-with-the-domain-10.html Wed, 04 Oct 2023 00:00:00 GMT
在前面的章节中，我们介绍了 DDD Lite、CQRS 和 Clean Architecture 等技术。即使单独使用它们是有益的，但它们一起使用效果最好。不幸的是，在实际项目中将它们一起使用并不容易。在本章中，我们将展示如何以最务实、最高效的方式连接 DDD Lite、CQRS 和 Clean Architecture。

我为什么要在乎？

从事编程项目类似于规划和建设住宅区。如果您知道该地区将在不久的将来扩张，您需要为未来的改进保留空间。即使一开始它可能看起来像是浪费空间。您应该为住宅区、医院和寺庙等未来设施留出空间。否则，您将被迫摧毁建筑物和街道，为新建筑物腾出空间。早点考虑一下会好得多。
情况和代码是一样的。如果您知道该项目的开发时间将超过 1 个月，那么您应该从一开始就牢记长远目标。您需要以不会妨碍您未来工作的方式创建代码。即使一开始看起来像是过度设计和大量额外的样板，您也需要牢记长远目标。
这并不意味着您需要规划将来要实现的每一项功能——实际上恰恰相反。这种方法有助于适应新的要求或对我们领域不断变化的理解。这里不需要大的前期设计。这在当今时代至关重要，因为世界变化非常快，谁不能适应这些变化，就可能会被淘汰。
这正是这些模式结合起来所给您带来的——保持恒定开发速度的能力。无需过多破坏和触及现有代码。
是否需要更多的思考和规划？这是一种更具挑战性的方式吗？您需要额外的知识才能做到这一点吗？当然！但从长远来看，这是值得的！幸运的是，您来对地方了。
但让我们把理论抛在脑后吧。让我们看代码。在本章中，我们将跳过设计选择的推理。我们已经在前面的章节中描述了这些。如果您还没有阅读它们，我建议您阅读一下——您会更好地理解本章。与前面的章节一样，我们的代码将基于重构真实的开源项目。这应该使示例更加现实并且适用于您的项目。
你准备好了吗？

让我们开始重构

让我们从 Domain-First 方法开始重构。我们将从领域层的介绍开始。因此，我们将确保实现细节不会影响我们的领域域代码。我们也可以全力以赴地理解业务问题。不是编写无聊的数据库查询和 API 端点。
领域优先方法对于救援（重构）和新建项目都很有效。
为了开始构建我的领域层，我需要确定应用程序实际在做什么。本章将重点关注Wild Workouts 中 Trainings 微服务的重构。我首先确定应用程序处理的case。在之前重构为 Clean Architecture 之后。当我使用混乱的应用层时，我会查看 RPC 和 HTTP 端点以查找支持的case。
我确定的功能之一是批准重新安排训练。在Wild Workouts中，如果在日期前 24 小时内提出重新安排训练的请求，则需要审批。如果参加者要求重新安排时间，则需要得到培训师的批准。当培训师提出要求时，学员需要接受。

从领域开始

即使它看起来不像您一生中见过的最糟糕的代码，但像 ApproveTrainingReschedule 这样的函数随着时间的推移往往会变得更加复杂。更复杂的功能意味着未来开发过程中潜在的错误更多。
如果我们是这个项目的新手，而且我们没有关于它的“萨满知识”，那么这种情况就更有可能发生。您应该始终考虑在您之后将从事该项目的所有人员，并使其能够防止他们意外破坏项目。这将有助于您的项目不会成为每个人都不敢触碰的遗产。当你刚接触这个项目时，你可能讨厌这种感觉，并且你害怕接触任何东西以免破坏系统。
人们每两年换一次工作的频率并不少见。这使得它对于长期项目开发变得更加重要。
如果您不认为这段代码可能会变得复杂，我建议您检查您所从事的项目中最糟糕的地方的 Git 历史记录。在大多数情况下，最糟糕的代码都是以“几个简单的 if”开始的。代码越复杂，以后简化起来就越困难。我们应该对新出现的复杂性保持敏感，并尽快尝试将其简化。

训练领域实体entity

在分析训练微服务处理的当前用例时，我发现它们都与训练相关。创建一个 Training 类型来处理这些操作是很自然的。
重构TrainingService的方法
重构TrainingService的方法
💡
名词==实体 ？ 这是发现实体的有效方法吗？嗯，不是真的。 DDD 提供的工具可以帮助我们在无需猜测的情况下对复杂领域进行建模（战略 DDD 模式，聚合）。我们不想猜测我们的聚合是什么样子——我们希望有工具来发现它们。事件风暴技术在这里非常有用……但它是一个单独章节的主题。 这个主题非常复杂，需要用几章来讨论。这就是我们很快要做的事情。 这是否意味着在没有战略 DDD 模式的情况下不应使用这些技术？当然不是！当前的方法对于更简单的项目来说已经足够了。不幸的是（或者幸运的是），并非所有项目都是简单的。
 
所有字段都是私有的以提供封装。这对于满足 DDD Lite 章节中的“始终在内存中保持有效状态” 规则至关重要。
由于构造函数和封装字段中的验证，我们确信 Training 始终有效。现在，对项目没有任何了解的人无法以错误的方式使用它。同样的规则适用于Training提供的任何方法。

在领域层审批

正如 DDD Lite 简介中所述，我们使用面向行为的方法构建我们的领域。不是靠数据。让我们在领域实体上对 ApproveReschedule 进行建模

使用命令编排

现在应用层可以只负责流程的编排。那里没有领域逻辑。我们将整个业务复杂性隐藏在领域层中。这正是我们的目标。为了获取和保存训练，我们使用存储库模式。

取消训练的重构

现在让我们看一下 TrainingService 中的 CancelTraining。
那里的领域逻辑很简单：您可以在训练日期前 24 小时取消训练。如果距培训时间不到 24 小时，但您无论如何都想取消培训：
  • 如果您是教练，学员将被取消训练，并额外参加一次课程（没有人喜欢在同一天改变计划！）
  • 如果您是学员，您将失去本次训练
当前的实施方式如下：
您可以看到某种用于在取消期间计算训练余额增量的“算法”。这对应用层来说不是一个好兆头。
像这样的逻辑应该存在于我们的领域层中。如果您开始在应用程序层中看到一些与逻辑相关的 if，您应该考虑如何将其移动到领域层。在其他地方测试和重用会更容易。
这可能取决于项目，但通常领域逻辑在初始开发后相当稳定，并且可以长期保持不变。它可以在服务、框架更改、库更改和 API 更改之间移动。
由于这种分离，我们可以以更安全、更快速的方式进行所有这些改变。让我们将 CancelTraining 方法分解为多个独立的部分。这将使我们能够独立测试和更改它们。
首先，我们需要处理取消逻辑并将训练标记为已取消。
这里没有什么真正复杂的。那挺好的！
第二个需要移动的部分是计算取消后训练余额的“算法”。理论上，我们可以将其放入 Cancel() 方法中，但在我看来，这会打破单一职责原则 和 CQRS 。而且我喜欢小功能。
但该放在哪里呢？一些对象？领域服务？在某些语言中，比如以 J 开头并以 ava 结尾的语言，这是有意义的。但在 Go 中，只需创建一个简单的函数就足够了。
代码现在很简单了。我可以想象我可以和任何非技术人员坐在一起，通过这段代码来解释它是如何工作的。
测试怎么样？这可能有点争议。测试代码将复制该函数的实现。计算算法的任何更改都需要将逻辑复制到测试中。我不会在那里写测试，但如果你想晚上睡得更好——为什么不呢！

将 CancelTraining 移至命令

我们的领域已准备就绪，现在让我们使用它。我们将按照与之前相同的方式进行操作：
  1. 从存储库获取实体
  1. 编排领域内容
  1. 调用外部trainer服务取消培训（此服务是“教练日历”的关键点） )
  1. 返回要保存在数据库中的实体。

存储库重构

存储库的初始实现非常棘手，因为每个用例都有自定义方法。
由于引入了training.Training实体，我们可以拥有一个更简单的版本，其中一种方法用于添加新训练，另一种方法用于更新。
正如存储库模式中一样，我们使用 Firestore 实现了存储库。我们还将在当前的实现中使用 Firestore。请记住，这是一个实现细节 - 您可以使用任何您想要的数据库。在上一章中，我们展示了使用不同数据库的示例实现。

连接一切

现在如何使用我们的代码？我们的端口层呢？感谢 Miłosz 在《整洁架构》中所做的重构，我们的端口层与其他层解耦。这就是为什么在这次重构之后，它几乎不需要任何重大改变。我们只是调用应用程序命令而不是应用程序服务。

在实际项目中如何进行这样的重构？

整洁架构分层
整洁架构分层
如何在实际项目中进行此类重构可能并不明显。进行代码审查并在团队层面就重构方向达成一致是很困难的。
根据我的经验，最好的方法是 Pair或 Mob编程。就算一开始，你可能会觉得浪费时间，知识分享和即时复习会在以后节省很多时间。得益于丰富的知识共享，您可以在初始项目或重构阶段之后更快地工作。
在这种情况下，您不应该考虑 Mob/Pair 编程所损失的时间。你应该考虑一下因为不做而可能损失的时间。它还将帮助您更快地完成重构，因为您无需等待决策。您可以立即就它们达成一致。在实施复杂的新建项目时，群体编程和结对编程也能完美地工作。
在这种情况下，知识共享尤其重要。我多次看到这种方法如何让项目在长期内进展得非常快。当你进行重构时，就合理的时间范围达成一致也很重要。并保留它们。
当您花费整整一个月的时间进行重构时，您可能很快就会失去利益相关者的信任，并且改进并不明显。尽快集成和部署重构也很重要。完美，每天（如果您可以在非重构工作中做到这一点，我相信您也可以在重构中做到这一点！）。如果您的更改长时间未合并和未部署，则会增加破坏功能的机会。它还会阻止重构服务中的任何工作或使更改更难以合并（并不总是能够停止周围的所有其他开发）。
但是什么时候知道项目是否复杂到可以使用 mob 编程呢？不幸的是，没有神奇的公式可以做到这一点。但您应该问自己一些问题：
  • 我们了解该领域吗？
  • 我们知道如何实施吗？
  • 最终会产生一个无人能审查的巨大拉取请求吗？
  • 我们是否可以在不进行群体/结对编程的情况下冒更糟糕的知识共享风险？

总结

我们到此结束。重构的完整差异可以在我们的 Wild Workouts GitHub上找到（注意，它很大！）。我希望在本章之后，您还会看到所有引入的模式如何很好地协同工作。如果还没有，请不要担心。我花了三年时间才把所有的点串联起来。但所花的时间是值得的。在我了解了一切是如何相互联系之后，我开始以完全不同的方式看待新项目。从长远来看，它使我和我的团队能够更高效地工作。还值得一提的是，与所有技术一样，这种组合并不是灵丹妙药。如果您正在创建的项目并不复杂，并且在开发 1 个月后不会很快被触及，那么将所有内容放入一个主包中可能就足够了。不过要注意，这 1 个月的开发时间很可能将变成一年！
 
]]>