雷米Remy

序 之前写过一篇python的领域驱动相关开发的文章，收到同事的称赞，但有些人说我是翻译抄袭的，顺便冷嘲热讽一下。刚好最近公司一些新项目都在往go里面迁移。但收到之前python/PHP影响颇深，思维固化。依然按照原先脚本语言的方式继续往上糊。但是又不知道怎么写好。刚好我负责了一个新的项目。实践一遍DDD。所以写几篇文章分享出来。 我们做错了什么？ 但凡讲DDD的时候，我们会被很多概念吓唬住，比如什么实体、值对象、CQRS 等等，听起来十分高端，十分上档次。但从来没有人说我们为什么这样做。为什么要弄出这么多概念来？存粹为了装逼吗？要搞懂为什么要理解以上概念，我认为更多应该理解我们错在什么地方了...

构建支持领域建模的架构 大多数程序员从未见过领域模型， 只见过数据模型 许多程序员在谈论架构的时候都有一种感觉：认为事情可以变得更好。他们经常拯救一个不知为何出了问题的系统，并试图把一些结构恢复成一个粪球。他们知道他们的业务逻辑不应该散布在各处，但他们不知道如何修复他。 而且，我发现，许多程序员在被要求设计一个新系统时，会立即开始构建一个数据库模式，而对象模型则是事后才想到（甚至可能压根就不想）。这就是一切开始出错的地方。相反，行为应该放在第一位，并驱动我们对其进行存储。 毕竟我们的客户并不关心数据模型。他们只关心系统的工作，否则他们只会使用Excle。 接下来的文章我们将讨论如何通过TDD方...

序 从事Python开发也有段时间了,企业开发Python对解决复杂度问题可能是每个Pythoner的痛，有些人专研语法，有些人沿用其它语言的思考模式。但是却没有一个合适的指导思考方式去构建应用程序。况且，领域编程并不是某项特定技术，而是一种组织和思考模式来应对复杂的业务，由于Python的简洁易懂的特性，不会贴大量的代码给读者造成负担，从而更加去偏向思考业务本身而非语法 本系列文章奖分为以下两大章 1. 领域驱动建模 2. 事件驱动架构 我们的设计错在哪了？ 当你听到“乱”这个词的时候，你会想到什么？也许你会想到嘈杂的菜市场，比如你的出租屋，看起来一切都混乱不堪，当你想到“整洁有序”这个词的...

为什么我要写这个系列 曾经在看完《测试驱动开发》后，我发现一大堆问题没解决，比如：如何最好地构建应用程序，让其易于测试，其实这也是最难的。因为我们绝大多数情况下，我们都因为不好测试而放弃。现在很多人流行所谓的DDD架构，也就是领域驱动编程。很多文章在说一些令人感到很牛逼的名词，譬如"六边形架构"， “端口与适配器”，“CQRS”，等等。但是我们必须承认，在未真正实践中做过这件事，我们可能真的无法理解到底是什么东西。幸运的是，我在网上看到了这么一个系列的文章，很好的解答了这个问题，他帮助我更好的思考代码的方法 TDD,DDD, 事件驱动架构 我们说烂了的管理复杂性的工具，以下排名不分先后 - 测...

前言 在我工作的过程中,不知为何,我常常与数据库打交道更多一点,最近在新公司当中.我依然看 到大量的数据库反模式,此篇就来细数哪些数据库当中的错误使用案例,本人能力有限,解决 方案并不能尽善尽美,但即便如此也是前车之鉴,后车之师,有则改之,无则加勉,安全生产,警 钟长鸣。 那么有哪些反模式 乱穿马路 目的: 存储多值属性 如,一篇博客可以拥有多个作者,且在数据结构上应该符合1NF. 反模式:格式化的逗号分割列表 下面就是一张不符合1NF的表格,用逗号分割作者列表,由于account_id类型为VarChar, 导致了引发长度不够,非作者ID,分隔符错误,查询统计十分困难,性能极为低下,等等一系...

前言 在我工作的这几年，设计模式这个词就不断萦绕于耳，为了学好设计模式，我曾不断的生搬硬套4人帮的著作(我是一名python程序员)，在不断的工程实践当中，越发发现，设计模式的本质并不是前人总结好的套路，他遵循一定的原则。也就是我们耳熟能详的“SOLID”，一旦你的软件遵循原则，那么他其实也是你自己的模式。可回过头来你会发现，遵循这些原则并不容易，在日常coding当中，我们经常会为了快点实现功能，而把原则抛向脑后。美其名曰：先实现！再优化！随后便陷入了怪圈，实现好了不想动->动了又怕出错->新的需求来了->没时间重构->继续用糟糕的实现的死循环怪圈！ 久而久之，代码变不可维护，开始可能是只有...