第一部分：构建支持领域建模的架构
大多数开发人员从未见过领域模型，只见过数据模型。
DDD EU 2017
我们与许多开发人员谈论架构时，他们都隐隐感觉到事情可以做得更好。他们通常试图拯救一个不知何故出错的系统，并试图将一些结构放回一团乱麻中。他们知道他们的业务逻辑不应该遍布各处，但他们不知道如何解决它。
我们发现，许多开发人员在被要求设计一个新系统时，会立即开始构建数据库模式，而将对象模型视为事后才考虑的事情。这就是一切开始出错的地方。相反，行为应该优先并驱动我们的存储需求。 毕竟，我们的客户并不关心数据模型。他们关心系统做什么；否则他们只会使用电子表格。
本书的第一部分着眼于如何通过 TDD 构建丰富的对象模型（在 [chapter_01_domain_model] 中），然后我们将展示如何使该模型与技术问题解耦。我们将展示如何构建持久性无关的代码，以及如何围绕我们的领域创建稳定的 API，以便我们可以积极地重构。
为此，我们介绍了四个关键的设计模式
如果您想了解我们前进的方向，请查看 [part1] 结尾处我们的应用程序的组件图，但如果现在您还看不懂也没关系！我们在本书的这一部分中逐个介绍图中的每个框。
我们还会花一些时间讨论 耦合和抽象，用一个简单的例子来说明我们如何以及为什么选择我们的抽象。
三个附录是对第一部分内容的进一步探索
-
[appendix_project_structure] 是我们示例代码的基础设施的详细说明：我们如何构建和运行 Docker 镜像，我们在哪里管理配置信息，以及我们如何运行不同类型的测试。
-
[appendix_csvs] 是一种“实践检验真理”的内容，展示了将我们的整个基础设施（Flask API、ORM 和 Postgres）替换为完全不同的 I/O 模型（涉及 CLI 和 CSV）是多么容易。
-
最后，如果您想知道使用 Django 而不是 Flask 和 SQLAlchemy 时这些模式可能是什么样子，那么 [appendix_django] 可能会让您感兴趣。