专题: DDD 复杂业务设计
按专题持续组织的技术文章，适合成体系阅读和追踪。
DDD 复杂业务系统设计（一）：为什么从“领域”开始，比从“数据库”开始更靠谱
先让复杂的部分和简单的部分清晰分开，设计本身才可被讨论、被复盘。
DDD领域驱动设计微服务发布于DDD 复杂业务系统设计（二）：领域与子域，把“学校/课程/学员”拆成三件事再说
好钢用在刀刃上，核心域决定壁垒，通用域决定效率，支撑域决定能不能跑。
DDD领域子域发布于DDD 复杂业务系统设计（三）：限界上下文，为什么“课程”在教务和市场是两种东西
脱离上下文的术语毫无意义，「课程」在教务与市场，从来就不是同一种东西。
DDD限界上下文通用语言发布于DDD 复杂业务系统设计（四）：实体与值对象，把“学员”和“地址”放进代码的两种姿势
实体回答「我是谁」，值对象回答「我是什么」，身份与描述本就是两件事。
DDD实体值对象发布于DDD 复杂业务系统设计（五）：聚合与聚合根，一个“选课单”应该装多少东西
聚合是一致性边界，不是对象的合集，边界之内强一致，之外只靠最终一致。
DDD聚合聚合根发布于DDD 复杂业务系统设计（六）：领域事件，让“作业提交”自动触发批改进度
领域事件是「已经发生」的事实，不是「将要发生」的命令，而幂等是这条事实的生命线。
DDD领域事件消息中间件发布于DDD 复杂业务系统设计（七）：分层架构，你的“业务代码”应该待在哪一层
让稳定的业务不依赖易变的技术，是分层架构的全部意义。
DDD分层架构依赖倒置发布于DDD 复杂业务系统设计（八）：整洁架构 vs 六边形架构 vs DDD 分层，我选哪一种
分层、洋葱、端口，都只是「让易变外部分离」这一句话的三种画法。
DDD整洁架构六边形架构发布于DDD 复杂业务系统设计（九）：中台，在线教育平台到底应该共享什么
中台解决的不是代码复用，而是「同一个用户走进同一个业务」的体验。
中台DDD数字化转型发布于更新于DDD 复杂业务系统设计（十）：从战略到微服务，一张图跑通 DDD+中台+微服务
DDD 是方法论，中台和微服务只是它落地的两种姿势。
DDD中台微服务发布于更新于