• 数据 vs 算法 = 上下文 vs. 聚合 从对应位置来看： “数据”=“上下文” “算法”= “聚合” 数据=上下文 首先，数据本身是上下文的一种体现，如果你熟悉写作文，那么作文要求你说明来龙去脉，上下文背景需要交待清楚，那么这些文字本身就是一种数据，一个领域中大
  • 学习成绩好的擅长答题，从而忽视了问题的创建能力培养，如何提出问题的能力比答题能力更重要，世界上伪命题比比皆是，提出好的问题=解决一半问题，战略高于战术。 所以，问题空间=解决方案空间
  • “We often fall into the trap of thinking of a boundary as something that separates one thing from another. We should rather think of a boundary as som icon
  • 为什么我们系统的模块耦合度如此之高？是因为他们缺乏凝聚力吗？ （banq注：为什么人员在团队之间流动这么频繁？为什么团队之间开会如此频繁？是因为这些团队内部缺乏凝聚力吗？缺乏核心凝聚吗？） 案例： 有人说： 我们的系统是自 COBOL 和 FORTRAN 时代以来我们 icon
  • 在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。 在这篇博客中，我们试图全面介绍用DDD模式对支付系统进行建模的做法。 简介 支付系统是一个相当复杂和多变的系统，从订单、欺诈、通知、与各种支付方式的整合到资金清算和结算，涉及面很广。 在处理一个复杂的 icon
  • 没有上下文的数据就是噪音！ 上下文为王 icon
  • 将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的[i]潜在[/i]摩擦接触点。 [url= icon
  • 谷歌工程主管乔·林奇的文章，获得SOLID原则作者鲍勃大叔点赞转发的文章： 作者推荐将SRP视为DDD原则的自然结果：跨DDD限制上下文共享的模型是不安全的。 单一职责原则 (SRP) icon
  • “关键系统启发式”，又称“批判的启发式扫描”或“CSH”，是基于实践哲学和系统思维的反思性实践的框架。 CSH的基本思想是支持边界批判，也就是批判性地处理边界判断的系统性努力。 边界判断决定了哪些经验观察和价值考虑是相关的，哪些被排除在外或被认为不太重要。 因为它们同时制约了“事实”和“价值”，所以 icon
  • Tomasz Jaskuła 是巴黎软件咨询公司 Luteceo 的首席技术官和联合创始人。Tomasz 拥有 20 多年作为开发人员和软件架构师的专业经验，曾就职于电子商务、工业、保险和金融领域的多家公司。他主要专注于创建能够提供真正业务价值、与战略业务计划保持一致并提供具有明显竞争优势的解决方案 icon
  • 我经常阅读有关领域驱动设计如何过于复杂或过度杀伤的评论。然后还有其他新的 DDD 想要应用它，尤其是技术模式，无处不在。所以问题是，你应该使用领域驱动设计吗？答案在中间的某个地方。 大型系统 首先，让我定义一些我将在这篇文章的其余部分中提到的内容。在谈论系统的设计时，我指的是一个足够大的系统，它会影 icon
  • 我们将设计一个基于经典遗留应用程序的进化事件驱动系统，类似于在世界各地的许多组织中可以找到的系统。这个练习将向我们展示事件驱动架构的潜力。 消息驱动与事件驱动区别 让我们考虑两个需要通过信号相互传递信息的松散耦合组件。在这两种范式中，组件异步传递信号，允许它们在不等待响应的情况下传输信息。细微的区别 icon
  • 在软件工程方面，我们的愿景是让 BBC 以其工程和内容而闻名。为此，我们必须进一步发展 BBC 作为产品和技术公司的理念。 我们的资产中有数百个微服务，所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作 icon
  • 需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字 icon
  • 你是把每个微服务放在它自己的 git 存储库中，还是使用 monorepo？如果是后者，您如何在同一个 repo 中处理多个服务？ 回答 1. 我一直为每个服务使用一个 repo，但这主要是因为我们在工作中使用 maven 和 GitHub。我发现 monorepo 的想法很有趣，但我一直无法找到正 icon
  • 在经营企业的过程中，不可能预见到可能发生的每一种情况，并事先为它们准备好可以自动执行的纯粹基于规则的方案。这是否意味着你不应该使用基于规则的方法？当然不是! 它的意思是，在许多情况下，你的规则方法需要对实时插入的情感、人类判断力和常识尽可能友好。 决策模型和决策表在这方面往往是很脆弱的。也许我们对决 icon
  • 互联网的关键架构原则之一是模块化; 模块化是一种设计原则，它有意使组件高度独立（“松散耦合”）; 当一个系统由具有可识别边界的较小的独立部分组成时，它就是模块化的。 在设计模块化架构时，系统架构师以最小化组件之间依赖关系的方式分解系统。 模块化系统可以从组成部分分解和重组。事实上，形式上纯模 icon
  • Vladik Khononov 是《学习领域驱动设计》一书的作者。在这一集中，我们深入讨论了领域驱动设计 (DDD) 和 Vlad，首先分享了为什么理解业务领域在软件工程中至关重要，以及 DDD 如何帮助在领域专家和软件工程师之间建立共同的理解。Vlad 随后解释了 DDD 中的两个重要设计，即战略 icon