领域驱动设计

充血模型该充到什么地步？先别急着定义"充血"。咱们看一段你大概率写过的代码——一个订单支付方法，它是怎么一点点烂掉的。这三行到十几行的变化，还只是"支付"一个方法。等到取消、改址、发货、退款全堆进同一个 Service，整个类膨胀到几千行、没人敢动的时候——回头一看，真正属于"支付"的逻辑，就是开头那个"把订单标记为已支付"的核心动作；后面多出来的校验、优惠、流水、消息、缓存，没有一条是支付本身。

vivo互联网技术

软件不是从数据开始，而是从现实开始 | KDC 系列 01作者：vivo 互联网存储团队 - Xiao Bo AI 合作者：ChatGPT（GPT-5.5）创作模式：Human-led, AI-collaborated 责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。当 AI 应用开始在运行时解释数据、选择工具并影响业务状态时，数据表示中的遗漏和歧义可能直接转化为行动风险。本文从退款案例出发，提出 Reality First 的观察顺序：先明确系统面对的领域现实，再讨论现实模型、数字表示以及验证反馈如何共同支撑

用UML表示的行业标准02汽车-AUTOSARDDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集

消息丢了怎么办：事务 Outbox 与兜底 CronJob（第106篇）第二季第 6 篇。拆解对象：DeepFlux 里一张叫 events_outbox 的数据库表——全平台所有"已经发生的事"（领域事件）都先落到它里面，再由后台慢慢消费。第 104 篇（DDD 六条铁律）验证过这套机制的前半段："事件和业务数据必须写进同一个事务"这条铁律，有集成测试守着。这篇接着讲后半段：写进去之后呢？谁来取？取的时候崩了怎么办？没人管的消息最后谁兜底？两篇之间没有依赖，不要求读过 104。不要求你懂消息队列，概念当场讲。

DDD 学了很多却用不上？因为你把“责任”和“时机”揉在了一起摘要：DDD 落地难，难在把“责任”和“时机”揉进同一个 Service。本文主张把它切开：模型、规则、事件承载“责任”，编排与一致性收管“时机”，再用一条固定流程咬合——业务只声明，时机交给框架。

把规则搬回家：三个 BC 的贫血→充血重构实录（第103篇）第二季第 3 篇。拆解对象：2026-06-02 同一天的三个 commit——一场"充血化"重构，一次把业务规则从代码里搬回领域模型的搬家。这篇不要求你懂 Go 或 DDD 术语，用到的概念当场讲。

DDD 六条铁律：让 CI 替你骂人——go-arch-lint 门禁实战（第104篇）第二季第 4 篇。拆解对象：DeepFlux 仓库里一道 264 行的架构检查配置（server/.go-arch-lint.yml）和它的 CI 门禁。这篇不要求你懂 Go 或 DDD，用到的概念当场讲，所有的"我跑过"都带 2026-09-04 的时间戳。

从"遍地 try-catch"到分层治理：用 pragmatic-ddd 的异常体系治好代码洁癖基于 pragmatic-ddd 的用户接口层、应用服务层、领域层、基础设施层四层模型，聊聊异常该在哪一层被"接住"。文中异常类（PragmaticException / BrokenRuleException / AclException）均来自框架真实实现。

本体论的基本核心概念本体不是某一张表，而是整个组织共享的语义模型：它定义了企业里有哪些实体类型、实体有哪些属性、实体之间如何关联、可以对实体执行哪些操作。

领域驱动设计：给 AI 划定上下文边界，告别“大泥球”代码AI 写一个功能，通常并不难，真正难的是：当 AI 连续写几十个、几百个功能以后，代码还能不能保持清晰？

程序猿秃头之路

DDD 系列：DTO、VO、DO、Entity 怎么区分上一篇文章中，我们把 DDD 项目的分层和目录结构整理了一遍。目录有了之后，新的问题马上就来了：一个订单请求从 Controller 进入系统，经过应用层、领域层和数据库，途中到底要用多少种对象？

程序猿秃头之路

DDD 系列：聚合和聚合根详解上一篇文章中，我们学习了实体和值对象。实体看身份，值对象看属性，这两个概念算是 DDD 战术设计里面最基础的砖块。

程序猿秃头之路

DDD 系列：实体和值对象详解上一篇文章中，我们通过事件风暴梳理了业务事件、命令和业务规则，也得到了一些领域模型的线索。从这一篇开始，我们进入 DDD 的战术设计。先从两个最基础、也最容易混淆的概念说起：实体和值对象。

[补注重发]《领域驱动设计》里的“领域愿景”属于伪创新从2019年开始，我发表了多篇领域驱动设计批评文章。现在是2026年。在不修改原文的情况下，我逐篇加上2026年的一些补充评注，重新发布。

Go 项目怎么组织：DDD 4 层 vs MVC vs 脚本式系列「企业级 AI Agent 实现拆解」E32 篇，Part 9 起步篇第二章。上一篇5 分钟跑通你的第一个 AI Agent把 Agent 跑起来了，代码全在一个 main.go 里。这篇讲什么时候需要分层、怎么分。

想你依然心痛

领域驱动设计(DDD)在嵌入式固件中的应用幸福的本质不是惊天动地的狂喜，而是持续收集微小雀跃的能力。大脑对剧烈刺激会快速适应，但对日常生活中细小的积极体验——阳光、好听的歌、一杯热茶——如果能刻意留意并品味，幸福感会持续累积。幸福不是山顶的烟花，而是沿途捡拾的闪亮石子。

小和尚同志

types.ts：设计理念在代码中的第一个载体今天在学习一个项目时，教程推荐先看 types.ts，给的理由：后面的模块都依赖这个公共类型定义。刚开始看觉得很合理，但仔细一想，又觉得这个理由过于浅显。

五个适配器：DeepFlux 如何把 Eino 接进 DDD 架构系列「企业级 AI Agent 实现拆解」E29 篇。前面 28 篇把 Eino 的机制讲清楚了。这篇和下篇换个角度：看 DeepFlux 实际怎么用 Eino——具体在 server/internal/agent/infrastructure/einoadapter/ 这个目录里，五个适配器做了什么。

流式管道：Pipe、StreamReader、背压控制系列「企业级 AI Agent 实现拆解」补充篇。E2 讲 Schema 时提到过 Pipe 和 StreamReader，但没有展开。这一篇补上——Eino 的流式管道是怎么工作的、背压（backpressure）怎么防止内存爆炸、5 个工具函数怎么组合出你想要的流处理逻辑。