DDD在实践过程中，如何实现如丝般顺滑的类目树管理？

本文共计3942个文字，预计阅读时间需要16分钟。

在上次DDD实践后，在类目树管理项目中再次实践DDD。从需求分析到建模及落地，结合个人体会，都是干货。背景+距离DDD实践反思已完，已过去一年，期间发生了很多事情。

在上次反思DDD实践之后，在类目树管理项目中再次实践DDD。从需求分析到建模和具体的落地，结合个人体会，都是干货。 背景

距离DDD实践反思写完已经过去一年，期间发生了很多事情，比如换了工作，细节按下不表；新团队的技术负责人对DDD在团队里的落地很关心，问最近有没有什么进展？这就很尴尬了：之前我接手并主要负责的XXX服务在现阶段是不太适合用DDD的，自身和外部其他几个服务的边界并不清楚（其中包含了一些历史技术债），而且当前处于一个变化比较快的阶段，也没有什么业务输入，不太适合贸然重构，所以并没有在XXX服务中搞DDD。

做技术总要有点追求嘛，虽然现阶段工作最高优先级还是保证业务快速发展，还是想继续实践下DDD的。
这时正巧一个老应用要做重构，在这个基础上一个新的类目管理功能，虽然是一个新的领域，但是产品文档确定的业务规则已经非常清晰，并且后续变化不会很大。美中不足的是需求对应的功能此时已经用传统的CRUD的方式写完了大半了，纠结了半天，还是决定：搞！

本文对于DDD的基础术语就不再单独讲解了，下面直接进入正题。

原则问题

关于DDD，我一年前观点基本没有变化，这里再总结归纳一下。要先确定是否满足以下条件，再考虑是不是要用DDD，不要为了DDD而DDD。永远记住：没有银弹！

实践时，你就会发现DDD在项目落地时做了很多折中，不能教条化地照搬。

1. 业务规则要有一定的复杂性和稳定性。