python 三层架构_Python架构模式

最近看了一本非常不错的Python软件架构方面的书：《Architecture Patterns with Python》。主要介绍了领域驱动设计，事件驱动架构在Python这门语言中的具体实践，读下来感觉撰文质量很高，有不少收获，大致列举一下：相比《Clean Architecture》，这本书结合了一个贯穿始终的具体项目来进行讲解，给出了各种具体代码实现，所以理解上会更加清晰直观，新手的友好度++。

叙述方面的思路非常清晰，在项目开发中我们碰到的具体问题是什么，接下来提出一种架构模式来解决，如何实现，最后也给出了设计的trade-off(这点感觉很多书都缺少)，任何架构模式都不是银弹，在解决问题的同时也会引入不一样的问题。

以往《Effective Python》，《Fluent Python》之类的书，更专注于Python的语言特性，底层细节用法方面，而在更高的软件架构层面，如何设计可维护可扩展的大型Python项目，之前很少有专著来论述。这本书很好的填补了这一空缺。

除了架构设计的主题，书中其实对各类最佳开发实践都有所覆盖，例如TDD和测试分级，类型注解，甚至配置部署，Docker打包方面也有涉及，非常实战派。

这么好的书，还是免费的！可以在这里在线阅读。

如果你对在大型项目上，Python 是个烂语言吗？这个问题感兴趣，那么这本书非常值得一看！以下还是按惯例，简单记录一下我个人的心得笔记。

DDD

大家最早开始接触到的软件系统架构，一般都是下面这个经典的三层结构：

这个结构非常符合我们的认知习惯，很多软件项目也都是基于这个结构开发起来形成的“单体应用”。在这个结构下，大体的代码调用逻辑一般也是上层调用下层，尽量减少同一层内的互相调用，绝对杜绝从下层调用上层。

但在看了《Clean Architecture》之后，突然发现业务逻辑调用数据存储层的做法是有问题的。一个比较浅层的痛点就是写测试，在这种结构下，在做业务逻辑测试时，往往需要mock/fake数据存储层，为了简便起见，很多时候就直接搞一个测试数据库来做相应的测试了。这就导致了测试本身的维护成本也很大，而且有了外部依赖之后测试运行速度也会变得很慢。

从更深层次看，采用了这种架构设计之后，我们在做新功能开发的一个习惯性思路就是先设计DB Schema，然后再设计上面的业务逻辑，以及表现层交互等。这个思路其实是有问题的，把设计的重心放在了本来其实是“细节”的数据存储上。如果我们从RDBMS换用了NoSQL，是不是整个系统的设计就变了？这显然逻辑上就不正确。如果思考的重心在存储层，也很容易在于业务方交流时忽略了业务的本质逻辑。

所以这时候引入DDD的思想也就比较自然了。DDD的原著有点难懂，我主要还是看《Clean Architecture》有了一些粗浅的理解。DDD的想法主要就是希望我们在做业务开发时，能以最核心的领域模型为中心来展开。一方面领域问题是我们做软件开发需要解决的核心问题，所以与产品，交互，测试，甚至于销售，客户来做各类交流和沟通时，领域建模及领域语言能让大家处在一个频道上，且专注于解决核心问题。另一方面，从软件架构层面，以领域模型为核心，让其它层面的逻辑去依赖领域模型，能让整体架构的灵活性和可扩展性更好。以《Clean Architecture》的经典示意图为例：

作者定义了离核心模型越远的部分，例如UI展现，DB存储这类，应该在越外层。从依赖关系上看要保证外层依赖内层，而不是反过来。这样的话例如我们想支持多种UI展现形式(Web，Mobile)，或者切换不同的数据存储(In-memory，File，D