搜索“DDD适用于哪些应用程序?”给出了以下答案:
可能有95%的所有软件应用程序属于“不太适合使用DDD”的类别。(见文章)
那么这一切到底是怎么回事???
我正在开发的应用程序主要是以数据为中心,但仍包含一些业务逻辑和规则需要应用。开始应用DDD技术是否会浪费时间?使用更传统的数据访问层、POCO模型和业务逻辑层是否更好?或者换句话说 - 除DDD之外,有哪些值得信赖的替代方案?
搜索“DDD适用于哪些应用程序?”给出了以下答案:
可能有95%的所有软件应用程序属于“不太适合使用DDD”的类别。(见文章)
那么这一切到底是怎么回事???
我正在开发的应用程序主要是以数据为中心,但仍包含一些业务逻辑和规则需要应用。开始应用DDD技术是否会浪费时间?使用更传统的数据访问层、POCO模型和业务逻辑层是否更好?或者换句话说 - 除DDD之外,有哪些值得信赖的替代方案?
抱歉,但如果DDD只是像Frans Bouma所说的一种思维方式,那么它就不会推荐像持久性忽略这样的东西。这等同于将其他人视为次等开发人员。
至少DDD有倾向于PI(持久性忽略),这是一种架构选择。它不再是一种思考方式;它已经是一种被提供给您的东西,并且大多数时间过于模糊,无法使用:“并非适用于所有情况”。
但是,决定是否采用PI的方式本身就是一个挑战,如果他对此感到不安,您不能称呼某个人(“编码者”)。
以一个具有类似MS Access界面的ERP包为例:网格带有运行总计,自动更新列和100,000条记录的无页面滚动。显然,DDD方法适用于思考如何处理此应用程序。但是多年来,我从未见过任何人-无论是在书籍还是在线上-都进行了有证据支持的解释,更不用说真实的代码示例了,即使是在任何想要交付商业级应用和用户体验的地方也是如此。
不想在这方面变得宗教化。DDD和DAL的支持者倾向于过于宗教化,并可能会驱走那些被咬一口但开放心态的人。许多人只想面对真实的经历(即思考),而不是得到只支持传教的猫、汽车和基本订单/订单项(即差代码)。
这里有一个非常相似的问题:你允许Web层直接访问DAL吗?
我在所有项目中都使用DDD。在较小的应用程序中,一些概念不适用,但我发现许多方面适用于所有项目,无论大小。
有时候那些占5%的人会比其他95%的人赚更多的钱 - 这就是DDD存在的原因。
它是为了特定的复杂大型系统而设计的。
DDD是一种需要长期维护的软件。对我来说,这意味着它需要表达随领域变化而变化的想法。当然,一个简单的应用程序可能非常适合短交付时间和短实现时间。但是,如果您需要扩展软件,则DDD原则将极大地帮助您。DDD可能一开始很困难,但一旦您理解了普遍语言和分离问题的思想,事情就会变得容易起来。
如果你再仔细读一下这篇文章,你会看到这样的内容:
对于5%的应用程序而言,DDD是非常适合的。在这些情况下,DDD可以帮助你解决非常困难的问题。在这种情况下,DDD可能就是你的经理指给你的难题的银弹。
这就是为什么有人对它大惊小怪的原因。
由于您的应用程序主要是数据为中心,因此您的架构可以主要采用传统的方法。
对于那些具有更多逻辑、潜在领域或价值对象的方面,您可以利用一些DDD思想来组织代码。
总的来说,“合理的选择”就是尽可能保持简单,有用时使用DDD概念,不要不必要地复杂化事物,正如文章所建议的。
我现在正在启动一个类似的项目,它既包含数据操作,又包含更多逻辑/算法驱动的领域。我同样希望采取DDDD的部分,以使该项目受益,但不会试图强加在可能产生反效果的领域上。