Stream the latest episode收听最新一期节目
Listen and watch now on YouTube, Apple, and Spotify. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.立即在 YouTube、Apple 和 Spotify 上收听或观看。本页顶部提供节目文字记录，底部提供时间戳。
Brought to You by本期赞助
• turbopuffer – vector and full-text search built on object storage: fast, 10x cheaper, and extremely scalable. Under the hood, the team are rewriting the tpuf storage engine. Follow along until it hits production at turbopuffer.com/v3• turbopuffer – 基于对象存储构建的向量和全文搜索引擎：速度快、成本降低 10 倍且具有极强的可扩展性。目前，团队正在重写 tpuf 存储引擎。请关注 turbopuffer.com/v3 以获取生产环境更新。
• Get a free introduction to property-based testing: through a live, online webinar hosted by Hillel Wayne (a recent podcast guest!), author of Logic for Programmers and Developer Educator at Antithesis. What if you only needed a single test to harden your system? RSVP here.• 获取基于属性测试的免费入门指南：通过由 Hillel Wayne（近期播客嘉宾，《Logic for Programmers》作者，Antithesis 开发教育专家）主持的在线直播网络研讨会学习。如果只需一个测试就能强化你的系统会怎样？点击此处预约。
• Entire – Git hosting, rebuilt for the agentic era. Entire hosts your code in-region, and is up to 89x faster than any other competitor. Mirror from GitHub with a single click – I’ve already done so.• Entire – 为智能体时代重构的 Git 托管服务。Entire 在区域内托管你的代码，速度比任何竞争对手快 89 倍。一键从 GitHub 镜像——我已经这样做了。
In this episode本期内容
Sam Newman wrote one of the most-read books about microservices (“Building Microservices”), but he calls them an architecture of “last resort.”Sam Newman 撰写了关于微服务最畅销的书籍之一（《Building Microservices》），但他称微服务为“不得已而为之”的架构。
In this episode of the Pragmatic Engineer podcast, Sam explains his thinking on this, and he’s certainly well placed to do so; he was in the room when the term “microservices” was coined. We discuss what teams get wrong when adopting microservices, why independent deployment matters, and how microservices can help teams work more autonomously.在本期《The Pragmatic Engineer》播客中，Sam 解释了他的这一观点。作为“微服务”一词诞生时的见证者，他无疑最有发言权。我们讨论了团队在采用微服务时常犯的错误、独立部署的重要性，以及微服务如何帮助团队实现更自主的工作。
We also peek into his new book, ‘Building Resilient Distributed Systems’, and Sam explains his three rules for distributed systems, why observability is essential, and also why it’s vital to take business context into account when deciding whether to fail open or fail closed on errors.我们还深入探讨了他的新书《Building Resilient Distributed Systems》。Sam 阐述了他关于分布式系统的三条原则、可观测性的必要性，以及在决定错误处理时是“开放式失败”还是“封闭式失败”时，考虑业务背景的重要性。
We also explore how AI is changing software development, from specs versus code as a source of truth to cognitive debt and cognitive surrender. Sam shares how modular architecture can help teams experiment with AI while maintaining understanding of the systems being built.我们还探讨了人工智能如何改变软件开发，从“规范与代码孰为真理来源”到“认知债务”与“认知投降”。Sam 分享了模块化架构如何帮助团队在试验 AI 的同时，保持对所构建系统的理解。
Takeaways from the conversation with Sam与 Sam 对谈的要点
1. In the room when “microservices” was coined. In the early years of the 2010s, James Lewis – Sam’s colleague at Thoughtworks – kept running into companies building service-oriented architectures where each service could be replaced quickly. At an architecture symposium in the Lake District, England, James pitched a name for this trend: “micro apps,” and in a room of about 10 people (including Sam), someone else suggested “microservices.” Lewis and Martin Fowler then wrote the first article on the topic in March 2014, ‘Microservices: a definition of this new architectural term’, and Sam published the book Building Microservices the following year.1. “微服务”一词诞生的见证者。2010 年代初，Sam 在 Thoughtworks 的同事 James Lewis 经常接触到一些公司，它们构建的面向服务架构中，每个服务都可以快速替换。在英格兰湖区举行的一次架构研讨会上，James 为这一趋势提出了一个名称：“微应用（micro apps）”。在一个约 10 人的房间里（包括 Sam），有人提出了“微服务（microservices）”。Lewis 和 Martin Fowler 随后于 2014 年 3 月发表了关于该主题的第一篇文章《Microservices: a definition of this new architectural term》，Sam 则在次年出版了《Building Microservices》一书。
2. Sam spent 18 months teaching Googlers how to write good automated tests. In 2007, Sam was embedded at Yahoo and Google as a ThoughtWorks consultant, alongside people from Pivotal Labs. Their job was to teach engineers how to write automated tests, and code that’s testable. He recalls that some Google devs did not believe it was possible to write automated functional tests for websites, until Sam and his colleagues showed them how Selenium works!2. Sam 曾花 18 个月教导 Google 工程师如何编写优质的自动化测试。2007 年，Sam 作为 ThoughtWorks 顾问入驻 Yahoo 和 Google，与来自 Pivotal Labs 的人员一起工作。他们的任务是教工程师如何编写自动化测试以及可测试的代码。他回忆道，一些 Google 开发人员起初不相信能为网站编写自动化功能测试，直到 Sam 和同事们向他们展示了 Selenium 的工作方式！
3. Sam spent 10+ years at a large company, three years at startups, and has been independent for more than a decade. After 13 years at Thoughtworks, he quit to avoid becoming “institutionalized.” He recalls thinking he could hang around at Thoughtworks and grow bitter. “So I’ll just go now.” He then worked at three different startups before going independent, which he’s now done for 15 years. The biggest challenge of being your own boss? He says: “The problem of working for yourself is that the boss is frequently an a*****e. So, current Sam frequently is cursing past Sam for the commitments he made!”3. Sam 在一家大公司工作了 10 多年，在初创公司工作了 3 年，并已独立工作了十多年。在 Thoughtworks 工作 13 年后，他辞职以避免变得“体制化”。他记得当时想，如果继续留在 Thoughtworks，自己可能会变得愤世嫉俗。“所以我现在就走。”之后他在三家不同的初创公司工作，然后开始独立执业，至今已有 15 年。作为老板最大的挑战是什么？他说：“为自己工作的问题在于，老板经常是个混蛋。所以，现在的 Sam 经常在咒骂过去做决定的自己！”
4. So, what’s a “microservice?” Sam gives two definitions: a clear one, and a softer one:4. 那么，什么是“微服务”？Sam 给出了两个定义：一个明确的定义，一个较宽泛的定义：
Independently deployable service. The “clear” definition: as long as, upon a change to a system, it can be independently deployed – without any other services needing to be deployed –, you can call it a microservice.可独立部署的服务。明确的定义：只要系统发生变更时，该服务能够独立部署——无需部署任何其他服务——你就可以称之为微服务。
Clear boundaries around the business domain. The “softer” definition: services split by business function (not by technical layer) can also be called microservices.业务领域界限清晰。较宽泛的定义：按业务功能（而非技术层）拆分的服务也可以称为微服务。
5. Three rules of distributed systems: Sam sometimes struggled to recall the eight fallacies of distributed computing, and so he boiled them down to the three that cause the most problems:5. 分布式系统的三条原则：Sam 曾难以记住分布式计算的八大谬论，因此他将其提炼为最容易引发问题的三条：
1. Information takes time to travel. You cannot send information instantaneously from point A to point B. This is basically the “speed of light” constraint.1. 信息传输需要时间。你无法瞬间将信息从 A 点发送到 B 点。这基本上是“光速”限制。
2. Sometimes, the thing you want to talk to isn’t there. That is, resources can and do go offline.2. 有时，你想与之通信的对象并不在线。也就是说，资源可能会离线。
3. Resources are not infinite; you will eventually run out of things like CPU, memory, storage, and networking bandwidth.3. 资源不是无限的；你最终会耗尽 CPU、内存、存储和网络带宽等资源。
In Sam’s experience, most distributed systems outages are caused by #3; resource pools running out.根据 Sam 的经验，大多数分布式系统故障都是由第 3 条引起的；即资源池耗尽。
6. Dealing with idempotency: keys or fingerprints? Idempotency is performing the same operation multiple times and it having the same effect as if done once only. For example, if you repeatedly hit the “down” button for an elevator, nothing more happens than what happened upon that first press: multiple button smashes don’t bring more elevators your way. Payments are a classic example where idempotency is needed: when you retry or refresh a payments page, you should not be charged twice.6. 处理幂等性：密钥还是指纹？幂等性是指执行同一操作多次，其效果与执行一次相同。例如，如果你反复按电梯的“下行”按钮，效果与第一次按下时完全相同：多次猛按按钮不会引来更多的电梯。支付是需要幂等性的典型例子：当你重试或刷新支付页面时，不应被扣款两次。
There are two common ways to deal with idempotency:处理幂等性有两种常见方法：
Idempotency keys: a client sends a unique identifier (usually a UUID) that is the idempotency key. The server makes sure operations with the same idempotency key are executed only once. It’s clean to build but hard to retrofit, which involves changing both the client and server.幂等性密钥：客户端发送一个唯一标识符（通常是 UUID）作为幂等性密钥。服务器确保具有相同幂等性密钥的操作只执行一次。这种方法构建起来很简洁，但难以事后添加，因为它需要同时修改客户端和服务器。
Fingerprints: the client sends nothing, but the server creates a “fingerprint” of the request by hashing relevant fields. It’s easy to retrofit later (only need to change the server), however, legitimate requests can be rejected as duplicates, and duplicate requests could still happen. Sam describes a Danish payment system he worked on that rejected purchases of the same value within a 5-minute period while it did the fingerprinting.指纹：客户端不发送任何内容，但服务器通过对相关字段进行哈希处理来创建请求的“指纹”。这种方法易于事后添加（只需修改服务器），但合法请求可能会被错误地拒绝为重复请求，且重复请求仍可能发生。Sam 描述了他曾参与的一个丹麦支付系统，该系统在进行指纹识别期间，会拒绝 5 分钟内同等金额的购买。
7. Four concepts of resiliency: Sam frequently references the four outcomes for military systems, explained by David Woods:7. 弹性的四个概念：Sam 经常引用 David Woods 解释的军事系统中的四个结果：
Robustness: systems continue to function as intended, for example, when Kubernetes replaces a failing pod. A downside of robustness is that it can add complexity, and more complex systems have more ways to fail.鲁棒性（Robustness）：系统继续按预期运行，例如当 Kubernetes 替换故障 Pod 时。鲁棒性的缺点是它可能增加复杂性，而更复杂的系统有更多的失败方式。
Rebound: how quickly the system recovers when something goes wrong.回弹（Rebound）：系统在出现问题后恢复的速度。
Extensibility: dealing with surprises and being able to stretch the system’s support to deal with new needs可扩展性（Extensibility）：应对突发状况，并能够扩展系统的支持能力以满足新需求。
Adaptability: the system changing to support new functions. Resilient systems are adapted, even between incidents.适应性（Adaptability）：系统为支持新功能而进行的变更。弹性系统即使在事件发生期间也会进行调整。
8. What if code is a side effect of collaboration? When Sam was at Thoughtworks, some clients refused to do pair programming as a practice because they could only see one developer typing and the other doing nothing, which is a waste. Martin Fowler’s dictum that “programming is not typing” helped Sam to explain to clients that typing out code is an output, but not an outcome.8. 如果代码是协作的副产品呢？Sam 在 Thoughtworks 时，一些客户拒绝进行结对编程，因为他们只能看到一个开发人员在打字，另一个什么也不做，认为这是浪费。Martin Fowler 的格言“编程不是打字”帮助 Sam 向客户解释，敲出代码是产出，但不是成果。
Sam conceives programming as building a system collectively, and code is one of the mechanisms delivering the system. Now that with LLMs we no longer spend most time typing out code, we’ll discover the next bottleneck in creating good software. Could it be delayed feedback cycles?Sam 将编程视为集体构建系统的过程，而代码是交付系统的机制之一。现在有了大语言模型（LLM），我们不再把大部分时间花在敲代码上，我们将发现创建优质软件的下一个瓶颈。会是反馈周期延迟吗？
9. Hedging the vendor options is sensible when integrating AI into systems. It’s hard to tell which AI companies have long-term, sustainable business models and which don’t, so it’s the responsible thing when designing systems to hedge the providers. Aim to be multi-vendor, multi-model in your choices, so you can easily change the vendor or model layer. Also, consider if you can swap out LLM-powered functionality for deterministic code that runs faster and cheaper.9. 在将 AI 集成到系统中时，对冲供应商选项是明智的。很难判断哪些 AI 公司拥有长期、可持续的商业模式，哪些没有，因此在设计系统时，对冲供应商是负责任的做法。目标是在选择中实现多供应商、多模型，以便你能轻松更换供应商或模型层。此外，考虑是否可以用运行速度更快、成本更低的确定性代码来替代基于 LLM 的功能。
10. We must resist “cognitive surrender” to AI. Sam believes that more AI usage is leading to less critical thinking – or could we be using it wrong? He says: “The original pitch of AI was it was going to free us from drudgery. We’d have less toil, and we can focus more on critical thinking and smarts. However, much of our current use of AI is not freeing us up from critical thinking! It’s causing more context switching and leaving less time for thinking. People are working longer hours; we’ve got studies that show this.10. 我们必须抵制对 AI 的“认知投降”。Sam 认为，AI 使用量的增加导致批判性思维减少——或者我们是否用错了？他说：“AI 最初的卖点是它将把我们从繁重的工作中解放出来。我们将减少苦差事，从而专注于批判性思维和智慧。然而，我们目前对 AI 的大量使用并没有让我们从批判性思维中解放出来！它导致了更多的上下文切换，留给思考的时间更少了。人们的工作时间更长了；已有研究证明了这一点。
But [longer hours and more context switching] is not necessarily AI’s fault. It’s just how we’re using it.”但这[更长的工作时间和更多的上下文切换]不一定是 AI 的错。这只是我们使用它的方式问题。”
Putting in the effort often leads to better results. For example, when writing Building Resilient Distributed Systems, Sam used NotebookLM for research, but he manually clicked through each link it surfaced, and checked whether it was information he wanted to reference.付出努力通常会带来更好的结果。例如，在撰写《Building Resilient Distributed Systems》时，Sam 使用 NotebookLM 进行研究，但他会手动点击它呈现的每个链接，并检查这是否是他想要引用的信息。
11. Starting with modules encourages better software architecture. Also: production is truth. I asked Sam for advice on what to do to get better at designing systems:11. 从模块化开始有助于更好的软件架构。此外：生产环境即真理。我请教 Sam 关于如何提升系统设计能力的建议：
Start by thinking carefully about module boundaries and the connections between them从仔细思考模块边界以及它们之间的连接开始。
When you use AI, allow it to roam freely, but only inside the module structure that you have designed!当你使用 AI 时，允许它自由发挥，但只能在你设计的模块结构内！
12. Much of the tech world might still be naive about what an LLM is. As Sam said:12. 科技界很大一部分人可能对 LLM 的本质仍然很天真。正如 Sam 所说：
“I think the tech world in general is quite naive about AI and fundamentally misunderstands what an LLM is. For example: why did the LLM delete my database? Well, because it has no concept of causality. They have no concept that if I do A, B happens.“我认为整个科技界对 AI 都相当天真，从根本上误解了什么是 LLM。例如：为什么 LLM 删除了我的数据库？嗯，因为它没有因果概念。它们没有‘如果我做 A，就会发生 B’的概念。
LLMs are not world models. World models have been around for a long time. They predate LLMs. So if you had the appropriate model and the appropriate inputs, world models could at least get to the point of ‘if I do X, then Y happens and I’ve been told not to do Y.’ LLM 不是世界模型。世界模型已经存在很长时间了，它们早于 LLM。因此，如果你有合适的模型和合适的输入，世界模型至少可以达到‘如果我做 X，那么 Y 就会发生，而且我被告知不要做 Y’的程度。
I think we expect LLMs to do more than they actually can do, because they seem so smart. This leads us to overestimate their capabilities a bit too much. But the nature of LLMs is why all the guardrails around LLMs are really not going to be the right long-term solution.”我认为我们期望 LLM 做得比它们实际能做的更多，因为它们看起来太聪明了。这导致我们有点过度高估了它们的能力。但 LLM 的本质决定了围绕 LLM 的所有护栏在长期来看都不会是正确的解决方案。”
Sam’s comments feel very timely, given Opus 5.5 just formatted the hard drive of a dev who ran the model with the —dangerously-skip-permissions tag, and was surprised to see all of his data gone.Sam 的评论非常及时，鉴于 Opus 5.5 刚刚格式化了一位开发人员的硬盘，该开发人员在运行带有 --dangerously-skip-permissions 标签的模型后，惊讶地发现他所有的数据都没了。
Finally, recommended reading to get better at software architecture. Sam’s recommendations:最后，推荐阅读以提升软件架构能力。Sam 的推荐：
Fundamentals of Software Architecture by Neal Ford and Mark Richards.《Fundamentals of Software Architecture》，作者 Neal Ford 和 Mark Richards。
Balanced Coupling by Vlad Khononov《Balanced Coupling》，作者 Vlad Khononov。
On the criteria to be used in decomposing systems into modules: a paper by David Parnas from the 1970s original papers from the early 1970s, such as《On the criteria to be used in decomposing systems into modules》，David Parnas 在 20 世纪 70 年代发表的论文，以及 70 年代初的原始论文。
An architecturally-evident coding style: making your design visible: a paper by George Fairbanks, published in 2010. It’s an approach that allows the code to hint at the system’s architecture《An architecturally-evident coding style: making your design visible》，George Fairbanks 于 2010 年发表的论文。这是一种允许代码暗示系统架构的方法。
The Pragmatic Engineer deepdives relevant for this episode《The Pragmatic Engineer》中与本期相关的深度文章
• Scaling Uber with Thuan Pham (Uber’s first CTO)• 与 Thuan Pham（Uber 首任 CTO）探讨 Uber 的扩展
• What is good software architecture at Netflix?• Netflix 的优秀软件架构是什么样的？
• The past and future of modern backend practices• 现代后端实践的过去与未来
• What is reliability engineering, and the history of SRE• 什么是可靠性工程，以及 SRE 的历史
• How to debug large, distributed systems: Antithesis• 如何调试大型分布式系统：Antithesis
• Designing Data-intensive Applications with Martin Kleppmann• 与 Martin Kleppmann 探讨《Designing Data-intensive Applications》
• Building Bluesky: a Distributed Social Network• 构建 Bluesky：一个分布式社交网络
Timestamps时间戳
00:00 Intro00:00 开场
03:16 Sam’s path into tech03:16 Sam 的技术之路
09:32 Thoughtworks09:32 Thoughtworks
20:55 The rise of microservices20:55 微服务的兴起
33:37 Are specs becoming more important than code?33:37 规范是否正变得比代码更重要？
45:22 Building Resilient Distributed Systems (Sam’s new book)45:22 《Building Resilient Distributed Systems》（Sam 的新书）
52:35 Three rules of distributed systems52:35 分布式系统的三条原则
56:16 Observability56:16 可观测性
1:02:20 Resilience tradeoffs1:02:20 弹性权衡
1:07:54 Idempotency1:07:54 幂等性
1:15:58 Thundering herds1:15:58 惊群效应（Thundering herds）
1:21:03 Business context and resilience decisions1:21:03 业务背景与弹性决策
1:25:51 Resilience engineering: four concepts1:25:51 弹性工程：四个概念
1:32:42 AI and resilience1:32:42 AI 与弹性
1:36:26 AI’s limitations and where to use it1:36:26 AI 的局限性及使用场景
1:40:06 Cognitive debt and cognitive surrender1:40:06 认知债务与认知投降
1:45:02 Modular architecture and AI software factories1:45:02 模块化架构与 AI 软件工厂
1:51:53 Resources for learning software architecture1:51:53 学习软件架构的资源
1:55:30 Where to find Sam1:55:30 在哪里可以找到 Sam
References参考资料
Where to find Sam Newman:在哪里可以找到 Sam Newman：
• X: https://x.com/samnewman• X: https://x.com/samnewman
• LinkedIn: https://www.linkedin.com/in/samnewman• LinkedIn: https://www.linkedin.com/in/samnewman
• Website: https://samnewman.io• 网站: https://samnewman.io
Mentions during the episode:节目中提及的内容：
• Acorn Electron: https://en.wikipedia.org/wiki/Acorn_Electron• Acorn Electron: https://en.wikipedia.org/wiki/Acorn_Electron
• Commodore 64: https://en.wikipedia.org/wiki/Commodore_64• Commodore 64: https://en.wikipedia.org/wiki/Commodore_64
• Alstom: https://www.alstom.com• Alstom: https://www.alstom.com
• Fortran: https://en.wikipedia.org/wiki/Fortran• Fortran: https://en.wikipedia.org/wiki/Fortran
• Thoughtworks: https://www.thoughtworks.com• Thoughtworks: https://www.thoughtworks.com
• TDD, AI agents and coding with Kent Beck: https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent• 与 Kent Beck 探讨 TDD、AI 智能体与编程: https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent
• How Kent Beck shapes the software engineering industry: https://newsletter.pragmaticengineer.com/p/how-kent-beck-shapes-the-software• Kent Beck 如何塑造软件工程行业: https://newsletter.pragmaticengineer.com/p/how-kent-beck-shapes-the-software
• Extreme programming: https://martinfowler.com/bliki/ExtremeProgramming.html• 极限编程: https://martinfowler.com/bliki/ExtremeProgramming.html
• Growing Object-Oriented Software Guided by Tests: https://growing-object-oriented-software.com/• 《Growing Object-Oriented Software Guided by Tests》: https://growing-object-oriented-software.com/
• Dave Farley’s website: https://www.davefarley.net• Dave Farley 的网站: https://www.davefarley.net
• Jez Humble on X: https://x.com/jezhumble• Jez Humble on X: https://x.com/jezhumble
• Continuous Delivery: https://continuousdelivery.com• 持续交付: https://continuousdelivery.com
• Mike Bland’s publications: https://mike-bland.com/publications• Mike Bland 的出版物: https://mike-bland.com/publications
• How AI will change software engineering – with Martin Fowler: https://newsletter.pragmaticengineer.com/p/martin-fowler• 与 Martin Fowler 探讨 AI 如何改变软件工程: https://newsletter.pragmaticengineer.com/p/martin-fowler
• James Lewis on LinkedIn: https://www.linkedin.com/in/james-lewis-microservices• James Lewis on LinkedIn: https://www.linkedin.com/in/james-lewis-microservices
• Building Microservices: Designing Fine-Grained Systems: https://www.amazon.com/dp/1492034029• 《Building Microservices: Designing Fine-Grained Systems》: https://www.amazon.com/dp/1492034029
• Microservices Guide: https://martinfowler.com/microservices• 微服务指南: https://martinfowler.com/microservices
• Ben Christensen on LinkedIn: https://www.linkedin.com/in/benjchristensen• Ben Christensen on LinkedIn: https://www.linkedin.com/in/benjchristensen
• Scaling Uber with Thuan Pham (Uber’s first CTO): https://newsletter.pragmaticengineer.com/p/scaling-uber-with-thuan-pham-ubers• 与 Thuan Pham（Uber 首任 CTO）探讨 Uber 的扩展: https://newsletter.pragmaticengineer.com/p/scaling-uber-with-thuan-pham-ubers
• Stop being skeptical about AI for development with Charity Majors: https://newsletter.pragmaticengineer.com/p/stop-being-skeptical-about-ai-for• 与 Charity Majors 一起停止对 AI 开发的怀疑: https://newsletter.pragmaticengineer.com/p/stop-being-skeptical-about-ai-for
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html• 理解规范驱动开发：Kiro, spec-kit 和 Tessl: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• Chris Ford on LinkedIn: https://www.linkedin.com/in/ctford• Chris Ford on LinkedIn: https://www.linkedin.com/in/ctford
• Beyond Vibe Coding with Addy Osmani: https://newsletter.pragmaticengineer.com/p/beyond-vibe-coding-with-addy-osmani• 与 Addy Osmani 探讨超越“氛围编程”（Vibe Coding）: https://newsletter.pragmaticengineer.com/p/beyond-vibe-coding-with-addy-osmani
• Building Resilient Distributed Systems: https://samnewman.io/books/building-resilient-distributed-systems• 《Building Resilient Distributed Systems》: https://samnewman.io/books/building-resilient-distributed-systems
• Honeycomb: https://www.honeycomb.io• Honeycomb: https://www.honeycomb.io
• Monzo: https://monzo.com• Monzo: https://monzo.com
• How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt: https://margaretstorey.com/blog/2026/02/09/cognitive-debt• 生成式 AI 和智能体 AI 如何将关注点从技术债务转移到认知债务: https://margaretstorey.com/blog/2026/02/09/cognitive-debt
• Fundamentals of Software Architecture: A Modern Engineering Approach: https://www.amazon.com/dp/1098175514• 《Fundamentals of Software Architecture: A Modern Engineering Approach》: https://www.amazon.com/dp/1098175514
• Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems: https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480• 《Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems》: https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480
• Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy: https://www.amazon.com/Learning-Domain-Driven-Design-Vlad-Khononov-ebook/dp/B09J2CMJZY• 《Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy》: https://www.amazon.com/Learning-Domain-Driven-Design-Vlad-Khononov-ebook/dp/B09J2CMJZY
• Software Fundamentals: Collected Papers by David L. Parnas: https://www.abebooks.com/9780201703696/Software-Fundamentals-Collected-Papers-David-0201703696/plp• 《Software Fundamentals: Collected Papers by David L. Parnas》: https://www.abebooks.com/9780201703696/Software-Fundamentals-Collected-Papers-David-0201703696/plp
• Just Enough Software Architecture: https://www.georgefairbanks.com/book• 《Just Enough Software Architecture》: https://www.georgefairbanks.com/book
• Modern Software Engineering: https://www.youtube.com/c/ContinuousDelivery• 现代软件工程: https://www.youtube.com/c/ContinuousDelivery
—
Production and marketing by Pen Name. 制作与营销：Pen Name。
