• 高内聚低关联和SOLID原则是面向对象的设计原则,也是DDD用来划分有界上下文和聚合的原则,DDD聚合是一种高内聚低关联的对象,单一职责是划分不同上下文的主要原则,Shopify谈论他们如何使用这些原则将Rails单体切分为模块组件的过程,虽然他们文中只是简单提及了DDD领域驱动设计,但是他们这种整 icon
  • 敏捷的软件公司组织结构最好能映射到业务领的结构,公司组织结构不要映射到技术。 DDD创建了一个从领域映射到软件技术的架构。 如果有界上下文是商店、仓库和财务,那么架构中最大的可模块化部门就是商店、仓库和财务,而不是“前端”和“后端”之类技术的东西。 康韦定律(Conway's icon
  • 软件设计的目标是创建适合人类思维的块或切片。软件一直在增长,但人类的思维会达到极限,因此,如果要继续进行软件更改,我们必须进行切片和分块。 这意味着软件设计实际是人为人自己提供技术支持的过程(人类互助)。软件设计是人类关系中的一项练习(banq注:道德伦理也是一种人类关系)。 icon
  • 好的代码本身就是最好的文档。在您要添加注释文档时,问问自己:“如何改进代码,以便不需要这些注释文档?” 改进代码,然后对其进行记录以使其更加清晰。 - Steve McConnell 众说纷纭: [code]我猜这家伙也没有写测试 代码格式化也起着快速理解和编辑将 icon
  • 您所做的事情越复杂,即使只是将其结构化,是一种建设性的复杂性(如数据表结构设计,DDD聚合设计等,关联关系不能太多,虽然这是一种结构化关系,但是如果有很多1:N和1:2甚至N:N关系,则会复杂化)。复杂化会让排斥您的人也就越多。简单化就是无障碍。 我可以原谅建设性的复杂性:抽象哲学,高级艺术。但是, icon
  • 牢记业务上下文的技术决策建议,业务上下文是唯一的衡量软件质量的关键指标。 如果有事情不对劲,软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地,我们对更高层次的抽象感到不安:我们不再会像当初因缺乏理解而烦恼,而是知道系统确实属于有害反模式时,会更加不安。 不安情绪是我们即将面 icon
  • 编排Orchestration和编舞Choreography是微服务架构中的两种交互方式。 在编排Orchestration中,有一个控制器(“编排器”)控制服务之间的交互。它决定了业务逻辑的控制流,并负责确保一 icon
  • 我想明确指出我不是反微服务者,我将服务合并回到整体(单体/Monolith)中并不是为了摆脱微服务,目的是实现“大小正好”的整体。我正在做的事情是解决我团队的痛点。如果不能减少摩擦,我将不会花费太多时间(和机会成本)来提升,转移和重构旧代码。 每次这样做,我都会冒引入新错误并破坏用户体验的风险。将微 icon
  • 如果在线销售产品是您业务的核心部分,那么您需要构建可扩展,灵活且快速的电子商务数据模型。诸如Shopify和BigCommerce之类的大多数现成供应商都是为每月销售几百万美元订单的小型商店而建,因此许多从事大规模工作的电子商务零售商开始研究创建定制解决方案。 本文将研究您自己开始构建此基础结构需要 icon
  • [img] 您在图片中看到了什么?一块硬纸板?一些垃圾? 不是!这是模型! 它是西门子KG86NAI31L冰箱的模型。纸板看起来不像冰箱吗?—是的,但并不重要。模型不是真 icon
  • 最喜欢的(微服务)语录:“对于想要跨服务实现事务的架构师的最佳建议是:不要!” - 书籍《软件架构基础》 其他相关: 软件重用 icon
  • 领域驱动设计是一种设计系统(通常是软件)的方法,该方法强调在域专家和系统构建者之间创建通用语言。著名的DDD原则包括使用[url= icon
  • 数据库是神话般的资源,我们已经滥用了它们。如果你拥有一个超级稳定安全的关系数据库,那么它就可能大包大揽,它就可能变成一把锤子,用来解决一切视为钉子的问题。 在Tandem,我了解到支持公司业务的数据库是一个复杂而复杂的生物。它不仅需要提供对客户数 icon
  • Apache Kafka已成为跨微服务异步通信的领先平台。它具有强大的功能,可让我们构建健壮的,有弹性的异步体系结构。 同时,我们需要预料到潜在的陷阱。如果无法提前识别出可能(不,将要发生)的问题,将使我们面临易于出错和数据损坏的系统。 在本文中,我们将重点介绍这样的陷阱:处理消息的失败尝试。首先, icon
  • 我们如何才能快速地从整体变为微服务? 无法回答这个问题。首先,“迅速”就在窗外。你一个月都没弄糟。您将不会在一个月内修复它。其次,您希望从微服务中获得一些您目前无法获得的好处。那有什么好处?微服务不是重点。 拒绝了这个问题之后,我将继续回答。在我无法解释为什么无法快速更改微服务之前,如果强制转换是危 icon
  • 有些人说设计模式已经死了。真愚蠢! “设计模式”书籍是我们行业中出版的最重要的书籍之一。对于所有专业程序员来说,其中的概念应是基本知识。 设计模式就像现实生活中的谚语:这是开放了其他人的经验。 假设需要调用10种不同类型的设备,然后再打开它们,我会创建一个DeviceByNameProducer,然 icon