DDD是浪费时间吗？

Question

DDD是浪费时间吗？

oopdomain-driven-design

66

搜索“DDD适用于哪些应用程序？”给出了以下答案：

可能有95％的所有软件应用程序属于“不太适合使用DDD”的类别。（见文章）

那么这一切到底是怎么回事？？？

我正在开发的应用程序主要是以数据为中心，但仍包含一些业务逻辑和规则需要应用。开始应用DDD技术是否会浪费时间？使用更传统的数据访问层、POCO模型和业务逻辑层是否更好？或者换句话说 - 除DDD之外，有哪些值得信赖的替代方案？

- JacobE

7个回答

16

抱歉，但如果DDD只是像Frans Bouma所说的一种思维方式，那么它就不会推荐像持久性忽略这样的东西。这等同于将其他人视为次等开发人员。

至少DDD有倾向于PI（持久性忽略），这是一种架构选择。它不再是一种思考方式；它已经是一种被提供给您的东西，并且大多数时间过于模糊，无法使用：“并非适用于所有情况”。

但是，决定是否采用PI的方式本身就是一个挑战，如果他对此感到不安，您不能称呼某个人（“编码者”）。

以一个具有类似MS Access界面的ERP包为例：网格带有运行总计，自动更新列和100,000条记录的无页面滚动。显然，DDD方法适用于思考如何处理此应用程序。但是多年来，我从未见过任何人-无论是在书籍还是在线上-都进行了有证据支持的解释，更不用说真实的代码示例了，即使是在任何想要交付商业级应用和用户体验的地方也是如此。

不想在这方面变得宗教化。DDD和DAL的支持者倾向于过于宗教化，并可能会驱走那些被咬一口但开放心态的人。许多人只想面对真实的经历（即思考），而不是得到只支持传教的猫、汽车和基本订单/订单项（即差代码）。

- Iharizaka Rahaingoson

3

我知道... 我已经厌倦了愚蠢的汽车和OrderLine的示例。我进入真正的ERP项目的那一刻，就遭遇了一些非常困难的情况，这些情况很常见，但我所阅读过的所有DDD内容都没有涉及到这些情况。 - frezq

9

这里有一个非常相似的问题：你允许Web层直接访问DAL吗？

我在所有项目中都使用DDD。在较小的应用程序中，一些概念不适用，但我发现许多方面适用于所有项目，无论大小。

- Chuck Conway

同意-较小的项目可能不需要所有东西-实际上，一些较小的项目可能需要留下不同的东西。 - Preet Sangha

我的项目规模相当大...你认为DD在数据中心化方面会带来更多的伤害还是帮助？ - JacobE

8

有时候那些占5%的人会比其他95%的人赚更多的钱 - 这就是DDD存在的原因。

它是为了特定的复杂大型系统而设计的。

- Francis

并非总是如此……“货币”领域是一个相对较小的系统，受益于DDD，并经常用于在小范围内演示DDD的概念。 - JasonTrue

@JasonTrue：企业系统在概念上并不一定与金钱有关。 - UpTheCreek

我只是在逗趣地重复“money”，因为我的观点是，不仅是大型复杂系统，还有一些小系统可以从DDD中受益。 - JasonTrue

7

DDD是一种需要长期维护的软件。对我来说，这意味着它需要表达随领域变化而变化的想法。当然，一个简单的应用程序可能非常适合短交付时间和短实现时间。但是，如果您需要扩展软件，则DDD原则将极大地帮助您。DDD可能一开始很困难，但一旦您理解了普遍语言和分离问题的思想，事情就会变得容易起来。

- Preet Sangha

6

如果你再仔细读一下这篇文章，你会看到这样的内容：

对于5%的应用程序而言，DDD是非常适合的。在这些情况下，DDD可以帮助你解决非常困难的问题。在这种情况下，DDD可能就是你的经理指给你的难题的银弹。

这就是为什么有人对它大惊小怪的原因。

- Mnementh

3

你会看到这个：“不要期望奇迹，也要注意不要为了复杂化代码而过度设计——有时候简单确实更好。” - alchemical

@Luft Mensch => "简单胜于复杂，复杂胜于混乱。| @fedecarg" - Arnis Lapsa

5

由于您的应用程序主要是数据为中心，因此您的架构可以主要采用传统的方法。
对于那些具有更多逻辑、潜在领域或价值对象的方面，您可以利用一些DDD思想来组织代码。
总的来说，“合理的选择”就是尽可能保持简单，有用时使用DDD概念，不要不必要地复杂化事物，正如文章所建议的。

我现在正在启动一个类似的项目，它既包含数据操作，又包含更多逻辑/算法驱动的领域。我同样希望采取DDDD的部分，以使该项目受益，但不会试图强加在可能产生反效果的领域上。

- alchemical

7

DDD只是一个噱头，没有带来任何新的想法，它只是纯粹的旧面向对象编程/设计，偏袒最新的编码实践。"首先与领域专家交谈，确定关键抽象"是在任何30年前的面向对象编程书籍中都会读到的第一件事情。"将功能封装在领域类中，除非这样做没有意义"……当然！ - rustyx

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Frans Bouma · Accepted Answer

许多认为DDD对他们的项目有用的开发人员陷入了一个误区，即他们认为他们的工作就是编写代码。这不是事实。开发人员的工作是实现功能，以便通过软件解决问题。这导致结论：编写代码不是开发人员所做的第一步，而是最后一步：在编写代码之前，代码是整个过程的结果。

DDD并不是关于编写代码的，它不是一个十步成型的流程来获得优秀的软件，它关注的是在编写代码之前的整个过程，它关注的是深入了解问题的本质，谁参与了哪些信息流，这些元素是什么样子，它们如何相互关联等等。事实上，DDD最重要的部分是“创造一种语言，使领域专家和开发人员之间的交流变得可能，而不会产生歧义”。这就是Evans所谈的“普及语言”。这实际上使得编写代码之前的整个过程成为一个几乎没有被猜测的过程，事情是清晰和直截了当的（这是目标）。

问题在于“DDD在实践中如何运作”以及“有没有人能给我一个使用DDD编写代码的例子”等问题，实际上是来自于提出这些问题的人将重点放在了编写代码上，但他们不知道为什么要编写那段代码而不是其他代码。换句话说：如果你意识到DDD是关于发现你需要以怎样的功能和原因来进行编写代码，一切都会顺理成章。如何编写代码，那就取决于你自己。但是正如前面所说的那样：这已经不再是最大的问题，因为你已经知道你需要编写什么以及为什么。