抛开DDD的优点不谈，难道就没有一点缺点吗
好好好
26 Likes
ddd用来指导设计可以，开发么，dddd
DDD是什么？
我都不知道DDD是什么？谁来解答一下？我感觉平时代码都白写了。。
2 Likes
缺点肯定有，主要是这个卡组的赚卡能力太弱，先手的压制也不强，也就一个椅子王能看看。建议投入救祓少女
ddd=电动的，缺点就是容易坏，不好养护，自己修一下的话，到后面就失去原有的功能了，四不像，想堆
DDD 对团队要求极高
1 Like
1 Like
我觉得DDD就是一股浪潮，就像当年xx中台、微服务这些概念，设计都是美好的，但像电商业务上到一定的量的时候，才会发现其实有暗病
对于复杂的业务场景来说确实很方便。
缺点就是 要达成共识， 不然会变成一坨屎
DDD其实并没有什么不好，对于业务比较复杂的系统来说，按照业务单元来对系统拆分，也是实现系统整体业务逻辑的一个捷径，尤其是这个系统里很多业务路径会出现重复的时候。
但是对于一些业务逻辑比较简单的系统，或者是每种业务逻辑都是一根筋的那种，DDD就像是牛刀了，强行应用反而会让系统的整体实现变得臃肿。
1、门槛高；
2、团队凝聚力要高（人员变动几乎为0）；
3、人脉资源广；
门槛高就高在人员分工非常明确，领域专家（可能是产品经理、用户）和开发（实现），内部需要一套专业术语沟通，最难把控的还是限界上下文（领域）以及上下文映射（领域依赖关系），一个环节把控不好，就会成为一个大泥球（屎山）。
以项目为出发点，沉淀成一个产品，后续重构是可以往这上面靠的，毕竟业务需求明确，需求设想与把控都在范围之内；
不如MVC起手，转看整洁架构。
1 Like
我司以前项目重构的时候有往DDD靠拢过，后面逐步放弃了。
主要有两个原因
- 团队对DDD的架构理解不到位，同时没有较好的codereview机制，迁移到最后发现很多同事其实是在给MVC套壳子
- 没有沉淀出规范的文档，导致学习成本较高，新员工拉下来代码一脸懵逼，文档也只有出入参数，没有业务说明和流程图
好处也是有的，实现DDD的少部分功能，后续的维护工作异常的轻松，我成功的摸了几个月的鱼(bushi
1 Like
你应该放弃一切主流，加入无敌的电子龙
1 Like
电子龙，玩具罢了
From #develop:qa to 开发调优