DDD聚合

DDD中的错误抽象比其他设计方法具有更大的破坏性影响。这篇文章分享了 DDD 中代价最高的设计错误；导致单一和紧密耦合系统盛行的一个常见错误。 背景企业中存在很多臃肿而脆弱的客户应用程序接口，而针对这种脆弱性提出的

忒修斯之船悖论（Theseus' Ship Paradox）是一个古老的哲学问题，旨在探讨同一性和变化的问题。 具体来说，它的问题是：如果一艘船的每一个部分逐渐被更换，那么到最后，当所有的部分都被替换时，这艘船还是原来的那艘船吗？如果这些被替换下来的旧部分

我一直倾向于尽量避免Go struct结构体嵌入，因为我发现这样做会增加阅读难度，因为这个 "上帝结构体god struct "恰好实现了大量独立的接口，并被传递到很多地方。不过我还是想听听其他人的意见。 您对结构嵌入（尤其是实现trait接口时）

“注意力就是你所需要的一切”背后Transformer的发展和灵感的（真实）故事。 注意力Attention： 一种出色的（依赖于数据的）加权平均运算。它是一种全居性的汇集，一种reduction汇

Jeremy Carter 的文章《思考 Actor：第 1 部分》讨论了 Actor 模型作为管理现代软件应用程序（尤其是分布式系统）状态的框架。以下是主要要点的总结： 每个软件开发人员可能都接触过某种分层架构。我们倾向于将组件分类为最适合的层，

JavaScript 的（function() { } ）()结构初看起来可能令人困惑，但对于编写即时执行且自成一体的代码块来说，它却是一个非常有用的工具。 虽然 (function() { } )() 看起来像是大括号和小括号的奇怪组合，但它在 Java

在软件开发的动态环境中，代码内聚性的概念是创建高效且可维护的应用程序的基石。尤其是在Java这种以其健壮性和可扩展性而闻名的语言中，理解和应用内聚性原则可以显着提高软件项目的质量。 本文深入探讨了 Java 中的代码内聚性领域，提供了见解、实际示例和最佳实

业务需求场景： 商品应在提交订单时为客户保留。 仅仅将商品添加到购物车并不能保证产品的可用性。 客户不能将已经缺货的产品加入购物车。 事实上，这并不是什么花哨的要求。我曾经做过一个电子商务项目，就有这样的功能。当深入研究领域驱动设计时，我开始思考如何

展示一段示例代码 - Order 类。此类在我们的示例 DDD/CQRS/ES 应用程序中使用。我们正在

使用 Base64 编码字符串是一种广泛采用的存储通用唯一标识符 (UUID) 的方法。与标准 UUID 字符串表示形式相比，这提供了更紧凑的结果。在本文中，我们将探讨将 UUID 编码为 Base64 字符串的三种方法。 第一种方法：使用

根据 DDD 原则实现存储库和聚合可以封装领域逻辑并增强应用程序的可维护性。确定聚合边界需要深入考虑域和表设计，但这可以说是软件开发中更有趣的方面之一。 让我们考虑一下电子商务网站的购物车界面。假设有购物车和购物车商品的表。应用层用例 X 利用购物

在Rust中，"marker types"（标记类型）是一种特殊的类型，它们通常没有具体的数据，而是用于在编译时传达一些关于类型的信息，或者为了满足特定的 trait 约定。 这些类型通常被称为“标记类型”，因为它们在程序中充当一种标记，而不是用于

事件风暴是一种强大的技术，用于映射不同抽象级别的系统的复杂性。这种协作方法使团队能够可视化并理解域内的事件、操作和策略的流程。  大局级别在事件风暴的大局层面，主要目标是建立系统的总体视图。该阶段是整个过程

投影是从存储库加载的#DDD聚合 的子集，用于只读目的。 返回投影的方法通常在存储库级别上定义，使存储库接口了解应用程序中使用的所有可能类型的投影。

啥是事件溯源？为啥听起来这么麻烦？ 想象一下，你在玩一个超级复杂的存档游戏，每次你干点啥，比如买个装备、升级、打怪，游戏都会把你的每一步操作记下来，存成一个“事件日志”。这个日志就像你的游戏日记，记着你从开局到现在的每一步，比如“玩家买了把剑”“玩家升级到

GraphQL是一个强大的API设计工具，并提供了一些优于传统REST API的优势。但是GraphQL存在抓取不足或过度抓取 我们需要意识到下面认知陷阱，进而改变使用GraphQL方式，才能避免误用GraphQL导致的各种问题：