核心问题

业务规则应该住在哪里？

工程困境

PM 说“用户下单”，代码里却是：

insert_table_xyz(user_id, course_id)

这说明业务语言和代码语言断了。

思想模型

DDD 的核心不是复杂战术模式，而是：

业务专家和技术专家用同一种语言描述系统。

领域层应该承载业务规则，而不是把规则撒在 UI、SQL、controller 里。

好模型

placeOrder(accountId, courseId)
refundOrder(orderId)
grantAccessFromPurchase(purchaseId)

这些名字能和业务讨论对齐。

Atlas Action

拿一个 PM 需求，把其中的动词圈出来。检查代码里是否有同样的业务动作名。

小结

DDD 的第一步不是聚合根，而是让代码说业务语言。