我眼中的DDD

我眼中的DDD

最早接触DDD是在2018年，在接到一个事件记录系统的设计开发任务时。当时DDD在国内已经很火了，但在工作环境里还是个不太热的东西，周围并没有什么动静。在做完这个系统后，觉得自己甚至掌握了DDD，DDD就是聚合跟和界定上下文。当时也读了Eric Evans的领域驱动设计，很晦涩难懂，没有消化太多内容。

在近两年的开发实践中，DDD变得更加流行，工作中也因此组织了一些学习和培训。但关于DDD的定义却变得更为模糊，究竟什么是DDD，如何解释明白DDD，更远一点，如何写一本DDD的书?

我觉得DDD定义难下的原因，在于领域驱动设计书中，还提到领域模型，战略设计等很多层面的东西。如果用道法术器来分，那么看起来DDD既是道，同样也是法和术。

在我看来，DDD的定义应该是一种复杂软件的解决方案。这个解决方案思想是，统一业务和代码实现，减少翻译带来的复杂度问题。

那么如何解释明白DDD是什么呢？

在当前方法论没有固定下来的时候，是不具象化的，无法直接感触到。而人们对于这种问题的解决方法也很简单，具象化。为了解决具象化的复杂度，人又会选择由浅入深的方式。所以我觉得为了能够解释明白DDD，第一需要解释DDD能够解决的是哪种复杂度(DDD的核心本质，不关心其他手段)，第二是举例采用和不用DDD之间的差异。第三，实践经验和方法论。

如何写关于DDD的书呢?

如果入门，那么就可以使用能够解释明白DDD是什么的方式。

如果是详解，那么就应该是思想论、方法论和大型实践。现在的我知识储备和经验有所短缺，只能尝试从一个更高的角度去给出答案。我认为书的主要内容包含三个部分:

1. 常见方法论的比较
2. 如何提升建模能力
3. 一些实践及探索

如果DDD能够保持这个火热的程度，一定会变成类似现在的MVC、框架等模式，到了这个程度，基本上也就实现了业务描述开发的模式，软件行业可能也会更加两极分化。另一个方向是就是SAAS,PAAS。