想问下DDD模式除了把项目变复杂外?还有什么用处?
0
悬赏园豆：80
[已解决问题]
解决于 2019-12-05 10:04
RT 最好大神们能用几个简单的例子给小弟说明下?
因为在小弟看来,DDD模式除了把项目变的越来越复杂,什么接口 充血模型 贫血模型 维护量越来越高外并没什么用处
你说仓储模式是解决平滑替换数据库 我用EF 或Sqlsugar 一样能解决 并且不需要写一句代码
用DDD模式设计 这个要么一开始你的需求就必须非常明确,然后实际开发情况需求随时在变化,接口不可能不变定义一大堆接口说改就改 那这个模式到底有什么用?
我觉得 一般的 数据层 业务层 应用层 模型层 就完全够用了 而且也非常灵活 快速
而且微软也这么推荐的
用了DDD反而维护量大增
最佳答案
0
DDD是从业务出发去分析问题，解决问题，你上面说的主要是项目结构的复杂度，和具体业务是没有关系的。
这么讲吧，做一个项目，我可以用UI层+数据层去做，我也可以复杂点用数据层+业务层+应用层+模型层去做，我还可以用微服务的思路去做，无非就是技术实现上更复杂，但这和我的业务有什么关系呢，技术是技术，业务是业务，可能DDD的技术实现上看起来很复杂，但实际这种开发方式是从业务的角度去分析问题，指引开发者去解决问题而存在的。
“实际开发情况需求随时在变化,接口不可能不变定义一大堆接口说改就改 那这个模式到底有什么用?”，这个一看开发者对需求的理解程度和对业务分析的水平，二看实际情况，没有谁能保证自己定义的东西100%不会变，或者以后完全兼容变更，但是我们在软件设计之初就分析好业务和接口，对后续的开发是有极大好处的。
收获园豆：80
其他回答(4)
0
小项目搞DDD，就是增加复杂度，业务越复杂才能体会DDD的好处
0
DDD其实是需求人员的事情。第一个事情就是：教会需求人员写结构代码。
你觉得可能吗。至少也是需要业务人员做好整体业务结构图。并且是完善的业务结构图。
如果让需求人员讲解给程序员听。程序员去画业务结构图。这样的DDD是没有意义的。
所以DDD的主要难题是需求人员的水平高低。
另外如果DDD实现了。可以让程序员完全成为机器。只需要填充实现具体业务。
业务人员在思考需求时，也会对自己的想法又深刻认识。
可以让业务人员和程序员之间实现高效的沟通。开发效率也能提高不知道多少倍。
至于什么代码啊，仓储模式啊。都是次要的。
0
DDD就是一种更接近真实情况的对业务逻辑的模拟，代码的业务逻辑表现能力较强。项目逻辑复杂时可以用DDD。如果是简单的项目，用DDD反而麻烦。
0
最近也在学习DDD，我认为DDD的好处就是可用快速响应业务的变动。
DDD也并不一定要一开始就需求明确，DDD要明确的是核心领域。只要核心领域明确了，那后面的都是围绕核心领域展开的。
至于接口的定义的变动，那更easy了。应用层依赖领域层，而核心业务都在领域层中，接口变动那也是针对于应用层的业务逻辑变动，改动是很小的，核心领域一般是不会变动的。
对于企业级应用，相对于业务复杂度来说，维护量其实并不大。
而对于小型项目，如果业务不是很复杂，我认为没必要引入DDD。
