雷米Remy

TA的文章
  • Golang领域驱动实战:序章
    序 之前写过一篇python的领域驱动相关开发的文章,收到同事的称赞,但有些人说我是翻译抄袭的,顺便冷嘲热讽一下。刚好最近公司一些新项目都在往go里面迁移。但收到之前python/PHP影响颇深,思维固化。依然按照原先脚本语言的方式继续往上糊。但是又不知道怎么写好。刚好我负责了一个新的项目。实践一遍DDD。所以写几篇文章分享出来。 我们做错了什么? 但凡讲DDD的时候,我们会被很多概念吓唬住,比如什么实体、值对象、CQRS 等等,听起来十分高端,十分上档次。但从来没有人说我们为什么这样做。为什么要弄出这么多概念来?存粹为了装逼吗?要搞懂为什么要理解以上概念,我认为更多应该理解我们错在什么地方了...
    •  1
    •  2
    •  2020-12-09
  • Python领域驱动编程实践-第一章:领域建模
    构建支持领域建模的架构 大多数程序员从未见过领域模型, 只见过数据模型 许多程序员在谈论架构的时候都有一种感觉:认为事情可以变得更好。他们经常拯救一个不知为何出了问题的系统,并试图把一些结构恢复成一个粪球。他们知道他们的业务逻辑不应该散布在各处,但他们不知道如何修复他。 而且,我发现,许多程序员在被要求设计一个新系统时,会立即开始构建一个数据库模式,而对象模型则是事后才想到(甚至可能压根就不想)。这就是一切开始出错的地方。相反,行为应该放在第一位,并驱动我们对其进行存储。 毕竟我们的客户并不关心数据模型。他们只关心系统的工作,否则他们只会使用Excle。 接下来的文章我们将讨论如何通过TDD方...
    •  2
    •  2
    •  2020-03-02
  • python领域驱动编程实践-序章
    序 从事Python开发也有段时间了,企业开发Python对解决复杂度问题可能是每个Pythoner的痛,有些人专研语法,有些人沿用其它语言的思考模式。但是却没有一个合适的指导思考方式去构建应用程序。况且,领域编程并不是某项特定技术,而是一种组织和思考模式来应对复杂的业务,由于Python的简洁易懂的特性,不会贴大量的代码给读者造成负担,从而更加去偏向思考业务本身而非语法 本系列文章奖分为以下两大章 1. 领域驱动建模 2. 事件驱动架构 我们的设计错在哪了? 当你听到“乱”这个词的时候,你会想到什么?也许你会想到嘈杂的菜市场,比如你的出租屋,看起来一切都混乱不堪,当你想到“整洁有序”这个词的...
    •  0
    •  0
    •  2020-02-21
  • Python-领域驱动编程之序言
    为什么我要写这个系列 曾经在看完《测试驱动开发》后,我发现一大堆问题没解决,比如:如何最好地构建应用程序,让其易于测试,其实这也是最难的。因为我们绝大多数情况下,我们都因为不好测试而放弃。现在很多人流行所谓的DDD架构,也就是领域驱动编程。很多文章在说一些令人感到很牛逼的名词,譬如"六边形架构", “端口与适配器”,“CQRS”,等等。但是我们必须承认,在未真正实践中做过这件事,我们可能真的无法理解到底是什么东西。幸运的是,我在网上看到了这么一个系列的文章,很好的解答了这个问题,他帮助我更好的思考代码的方法 TDD,DDD, 事件驱动架构 我们说烂了的管理复杂性的工具,以下排名不分先后 - 测...
    •  1
    •  1
    •  2020-01-22
  • Sql反模式-如何应对各种数据库常见编程错误
    前言 在我工作的过程中,不知为何,我常常与数据库打交道更多一点,最近在新公司当中.我依然看 到大量的数据库反模式,此篇就来细数哪些数据库当中的错误使用案例,本人能力有限,解决 方案并不能尽善尽美,但即便如此也是前车之鉴,后车之师,有则改之,无则加勉,安全生产,警 钟长鸣。 那么有哪些反模式 乱穿马路 目的: 存储多值属性 如,一篇博客可以拥有多个作者,且在数据结构上应该符合1NF. 反模式:格式化的逗号分割列表 下面就是一张不符合1NF的表格,用逗号分割作者列表,由于account_id类型为VarChar, 导致了引发长度不够,非作者ID,分隔符错误,查询统计十分困难,性能极为低下,等等一系...
    •  1
    •  0
    •  2019-02-24
  • 单元测试与设计模式的艺术
    前言 在我工作的这几年,设计模式这个词就不断萦绕于耳,为了学好设计模式,我曾不断的生搬硬套4人帮的著作(我是一名python程序员),在不断的工程实践当中,越发发现,设计模式的本质并不是前人总结好的套路,他遵循一定的原则。也就是我们耳熟能详的“SOLID”,一旦你的软件遵循原则,那么他其实也是你自己的模式。可回过头来你会发现,遵循这些原则并不容易,在日常coding当中,我们经常会为了快点实现功能,而把原则抛向脑后。美其名曰:先实现!再优化!随后便陷入了怪圈,实现好了不想动->动了又怕出错->新的需求来了->没时间重构->继续用糟糕的实现的死循环怪圈! 久而久之,代码变不可维护,开始可能是只有...
    •  1
    •  0
    •  2019-02-19