DDD 领域驱动设计－如何 DDD？
注：科比今天要退役了，我是 60 亿分之一，满腹怀念～😭😭😭 前几天看了园友的一篇文章《 我眼中的领域驱动设计 》，文中有段话直击痛点： 有人误认为项目架构中加入 Repository，Domain，ValueObject 就变成了 DDD 架构 。没错，我就是这样，不过准确的来说，并不能称为 DDD 架构，而是我之前经常说的“ 伪 DDD ”设计，后来我还抽离出了一个伪 DDD 设计框架： DDD.Sample ，大家有兴趣的可以瞧瞧，在实际项目的开发中，我用它做过了几个不太大的项目，我个人觉得用起来很顺手，当然并没有真正的 DDD 设计，只不过用了一个空的架构而已，然后冠以”DDD 开发“的名号。 因为之前有过 DDD 设计的痛苦经历（短消息系统），具体表现就是，如果真正 DDD 设计，需要花费大量的时间和精力，可能几天都在思考一个问题或者考虑几行代码的编写，但最后也可能没什么结论或结果，并且这个过程是很艰难和痛苦的，所以我后来就变懒了，懒的去思考项目所表现的业务，也不再考虑如何去设计领域模型，只是在考虑如何让框架用起来更爽，DDD.Sample 前两个应用的实际项目，我都是在完善这个框架，比如 Repository 和 UnitOfWork 的设计等等，所以，关于领域模型的设计，就是一堆贫血模型。不过，后来应用的第三个项目，也就是上一个实际项目，我觉得不能再这样下去了