[译] Python架构相关：我们需要更多吗？

最近，我一直在学习有关应用程序架构的很多新东西。亲爱的读者，我想知道你是否对这些想法感兴趣，以及我们是否应该尝试围绕它构建更多的资源（博客、会谈等）。

我们应该如何构建一个应用程序来充分利用测试？

对我而言一切都始于这个问题。在我的书尾 ，我用结束章节讨论了如何充分利用你的测试，在单元、集成和端到端的测试中做出权衡，并对我没有真正理解的一些主题做出些模糊浅显的指示：端口与适配器（ports and adapters），六角架构（hexagonal architecture），函数式内核/命令式外壳（functional core imperative shell），干净架构（the clean architecture），等等。

从那之后，我和一个正在用 Python 积极实现这些模式的技术团队达成合作。其实，这些架构模式并不是什么新鲜事，人们多年来一直在用 Java 和 C# 进行探索。只是我对它们很陌生……从个人经验而言，我在这里可能会有些深入（我对你的反应很感兴趣），但它们对 Python 社区的大部分人可能也是个新鲜事？

随着我们的成熟，确实能感觉到越来越多的曾经的小项目和大胆的初创公司变成了复杂的业务和（偷偷的说）商业软件，所以这些东西可能会变得越来越显著。

我最初从测试的角度看待它，正确的架构真得可以帮助你充分利用测试，通过分离出一个业务逻辑核心（“领域模型”）并让其摆脱所有的架构依赖，它能完全的用快速、灵活的单元测试进行测试。最终让人感觉测试金字塔是一个可实现的目标，而非一个奢望。

关于该主题的经典书籍（均为 Java）

Evans 的领域驱动设计（DDD） 和Fowler 的架构模式都是很经典的书籍，任何对这些感兴趣的人都应该阅读。但如果你像我一样，费力阅读那些 public static void main AbstractFactoryManager之类的东西实在让人有点烦。也许一些更轻量级的、Python 化的介绍能让人感觉更加合理，少点云里雾里？

Python 领域中的一些现有资源：

Made 的首席架构师，尊敬的 Bob 先生，就我们现在讨论的问题写过一个分为四部分的博客系列。我开始时特别喜欢阅读它。这系列是 DDD 基本概念、端口与适配器/依赖倒置、和某种程度上的事件驱动架构的快速使用介绍。都是 Python 适用。（触发警告：Type Hints）。

1. Python 中具有命令处理模式（Command Handler pattern）的端口和适配器
2. Python 中的库（Repository）和工作单元模式
3. 命令和查询，处理程序（Handler）和视图
4. 为什么要用领域事件（Domain Events）？

在 io.made.com 上还有很多，但以上四篇为主要内容。我们希望得到一些关于它们的反馈，哪些被阐述到了，哪些需要进一步解释，等等。

另：一个去年圣诞节及时发布的的书，Leonardo Giordani 的 Python 干净架构（Clean Architectures in Python） 。这本书是两本书合二为一，第一部分是 TDD 的介绍，但第二部分有四章介绍了与我在这里讨论的类似的模式。

我也很喜欢一年前 David Seddon 的一个演讲 岩石河：如何构建你的 Django 单体应用（monolith） ，显示出其他人开始思考我们如何超越基本的 Django 模型/视图/模板架构。

在 Valentin Ignatev 的 DDD 资源列表 还有更多的内容，这是我最近在推特上看到的。似乎很多人对此都有想法。

号召行动：这个东西有趣吗？

Bob已经得到一些对他博客帖子很好的反馈，Leonardo 也有了一些很不错的初始销量，所以我感觉到 Python 社区的一些兴趣，但是我想对它进行一个理性考察。

• 这些东西有趣或者有意义吗？你要了解更多吗？
• 你用 Python 正在做的事超出 “基础网页应用开发” 或 “数据管道（Data Pipeline）”的范围了吗？你是否发现编写快速单元测试很困难？你是否开始想把你的业务逻辑从任何你使用的框架中解放出来？
• 你是否在使用 DDD 或任何 Python 的经典模式？你可能已有所有的答案，愿意告诉我吗？或者你只想告诉我一些适用你的答案和事情？
• 你认为这些东西听起来很抽象且没有意义吗？也许 Made.com 在 Python 领域里有点像大纲，因为我们用 Python 编写物流/ERP/企业软件，而这一切和你日常工作非常不同吗？
• 从这些主题的新指南而言，你认为 Python/动态语言社区最受益的是什么？

我很乐意听到你的意见。文末评论开放，或者你也可以在推特上给我留言@hjwp。