在Clojure社区中，人们经常讨论数据驱动开发这样的事情。就像您不编写任何代码或逻辑一样。相反，你声明数据结构，主要是map，然后申明：有一种 Deus ex Machina 可以评估这些map并执行这些操作。
当新人相信这些事情时那没关系。但当连经验丰富的程序员都讲述 DDD 带来的奇迹的童话故事时，我感到紧张。这是一个谎言。
我使用 Clojure 已有九年了，DDD 仅在极少数情况下有用。是的，在某些情况下，它确实节省了时间。但只是有时，并非总是如此！这是不公平的：人们在会议上谈论他们在项目中使用 DDD 取得了多么成功。但他们永远不会发表演讲，讲述他们用地图描述一切是如何搞砸的。
文章观点：
- 数据驱动开发有局限性，并不总是最好的方法。与单独的映射map相比，函数允许更灵活和可调试的逻辑。
- 数据驱动开发有望通过依赖映射等数据结构来表示逻辑和行为来简化编程。
- 随着时间的推移，复杂性不可避免地会增加。随着需求的变化，数据结构会发展成为设计不当的特定领域语言和解释器。
- 与简单的函数相比，调试也变得更加困难。虽然数据最初可以提供帮助，但只有通过保持代码简单、均匀分布并使用函数等标准设施而不是发明新方法才能避免真正的复杂性。
网友观点：
- DDD 走向极端，就像编写一个新的解释器一样，并不是一个好方法。“尝试编写一个新的解释器并不是一个好主意。”
- 使用映射而不是对象的类有优点和缺点，具体取决于语言。“Lisp 中的线条变得模糊，因为代码被显式编码为数据结构（树）。”
- 复杂的领域逻辑不应该被 DSL“掩盖”。“好的 DSL”解决方案可能不同于纯粹的 DDD 方法。
- 条件过滤数据（如 Prolog 中）可能比“硬编码的 OOP/命令式代码”更好。标签使中间步骤可读。