我一直在阅读我在本段所面对的DDD
对于以数据为中心的操作，您可能最好使用像Active这样的东西 记录模式，甚至是存储过程的DAL。你可能会发现一些好处 DDD更粗略的方面，也许使用了一些术语，但试图制作 DDD适合这里不会是愉快的经历。
以及这一个：
可能95％的软件应用程序属于“使用DDD不太好”的类别。 大多数基本上都是以数据为中心 - 大多数网站都是，大多数桌面应用程序都是...... 从根本上说，大多数数据更新和报告应用程序都是以数据为中心的。
那么，您怎么看？ 你接受这个意见吗？ 根据这些段落，我们无法将DDD用于大量的IT项目，我们可以吗？
答案 0 :(得分：14)
将这些数字简单地视为基于作者经验的一些价值观（Evans＆＃39;书籍出版超过13年前，事情发生了变化）。
首先，（遗憾的是）少数开发人员理解的是，DDD完全是一种心态，一种看事物的方式。就是这样。因此，您可以在每个项目中使用DDD，因为我们仍然需要首先了解域，而不管其实现如何。如果结果是域只是一堆数据结构，那么你就不需要让生活复杂化。特别是如果你正在建立一个愚蠢的人。应用程序，即数据库的UI。
但是，如果您正在构建一个需要了解业务语义（概念和行为）以便自动化的应用程序，那么它就是一个不同的故事，所有这些DDD概念将帮助您构建更易于维护的应用
所以它在很大程度上取决于你的应用程序，即使在那个应用程序中，事情也会有很大变化。您应首先了解应用程序的用途，然后了解它尝试表示的域（如果是这种情况）并为每个用例提供解决方案。在一个应用程序中，你可以有很多CRUD的东西，你可以非常有效地省去许多抽象和你可以有几个重要的概念和用例需要更好的理解和设计。同样重要的是你认为应用程序会随着时间的推移而改变多少。如果有迹象表明它会随着时间的推移而发展，那么抽象一些东西可能会更好，但这只是从设计的角度来看。此时的实现仍然可以是CRUDy。
如果您将方法论视为一组思维模式和概念，您可以在任何地方使用它，因为像DDD这样的东西不是“如何”。编码食谱。虽然它有一些特定的工具，但是，应用设计师应该决定它们是否适合您的应用。
简单地说，您必须使用DDD来确定（整个）DDD是否可用于您应用的某些部分。但再一次，DDD意味着战略方法，即思维方式。
从一开始就为整个应用决定解决方案是完全错误的。了解应用尝试解决的问题，并针对每个问题使用正确的解决方案。如果最终一切都只是CRUD，那就没关系。如果只使用DDD战术工具实现某些部件，那就同样好了，关键是要为问题找到最佳解决方案。
总之，要学习并理解DDD思维模式（那里有很多解释，专注于设计，而不是因为它们是错误的，所以不要考虑它是一个编码配方而只是在它中使用它为了确定应用程序需求的最佳方法。
答案 1 :(得分：4)
DDD是一系列创意。当你说，使用 it 时，我不确定你指的是什么。例如，如果要将业务映射到代码中，无处不在的语言可能是一个好主意。 值类型也很有用。
但像有界上下文和聚合根之类的想法？那么，以这种方式开发将会产生更大的成本，因为设计自然会变得更加复杂。在某些问题域中，有必要隔离域问题。那是因为问题很严重。换句话说，95％的系统无法解决需要复杂成本的难题。
我喜欢将DDD视为一种设计频谱 类似的东西：
<--CRUD----Active Record----Domain Model----DDD-->
从左到右，这些想法变得越来越复杂。当您正在改进代码设计时，您自然会从左向右移动。优秀的做法是尽可能晚地推迟有关设计（架构）的决策。所以，你总是可以从左边的东西开始向右移动。
答案 2 :(得分：4)
Vaughn Vernon在他的伟大着作中唤起了他的DDD scorecard。
如果您的应用程序是专门针对CRUD的，那么DDD将是YAGNI 否则，如果您的应用程序确实是面向任务的，捕获用户的特定意图，DDD可能真的对您有所帮助。