DDD是不是过度工程理论?

\
“仅在复杂域中使用DDD”,这是DDD专家用来避免回避“是否银弹”争论的口头禅,这样至少可以避免不愉快的争论。
但是我们想知道到底什么是复杂的域?这样才能知道何时使用DDD。

从战略角度来看,我们可以随时使用DDD,剩下的问题是:我应该何时从战术角度使用DDD?我什么时候应该实现六边形架构,CQRS / ES和其他类似的东西呢?

不在CRUD软件中?
无论我们选择何种实现,软件都是业务抽象。当我们选择CRUD实现时,我们打赌未来的软件将具有很少的功能。我们打赌我们不需要很多抽象。由于领域的认知负荷将保持低水平,这意味着我们可以将业务逻辑与技术术语混合,而无需构建难以管理的软件。

根据我的经验,许多应用程序都是以简单的CRUD开始的,但它们很快就发展成为对业务更复杂和有用的东西。不幸的是,我们将它们编码为简单的CRUD,这导致了大量的混乱。当然不是故意的,日复一日地增加一点复杂性使得很难抓住解决方案的整体复杂性。我们是沸水的青蛙而不自知。

过度工程理论
挑战在于找到在什么时候我们的简单CRUD应用程序成为更复杂的业务应用程序?

我的理论是,我们一直在考虑战术DDD过度工程的模式。因为我们无法感受到我们日复一日建立的软件的复杂性。但是当我们开始另一个项目时会发生什么?肯定愿意从头开始重写整个软件。

寻找拐点
我们想要找到实施战术DDD模式变得有趣的时候,尽管它有成本。

解决方案的一部分可能是检查新来者需要多长时间才能进入生产级别工作编码?当这个过程时间太长时,说明还有改进的余地,而战术模式可以帮助降低代码复杂性。帮助提高新人快速进入生产能力的效率。
另一种解决方案可能是要求不同的DDD专家进行一些审核,但可能会更昂贵。
一个更简单的解决方案可能是假设软件将变得更加复杂。这意味着我们应该日复一日地研究哪种战术模式能够满足我们的需求。

请记住,战术DDD模式是一个全世界的实践,全部使用所有这些模式是不可取的。在合适的时间挑选好的又是困难的。

我什么时候应该使用战术DDD模式?
我没有一个明确的答案,只是一个经验观察:我已经看到无数的软件以CRUD方式实现,这将通过DDD战术方法得到极大改善。我已经看到没有使用战术DDD方法实现的软件可以通过CRUD实现大大改进。


“如果你认为好的设计是昂贵的,你应该看看糟糕设计的成本。”