我正在寻找见解/论文/文章等，是否可以使用完全声明性的域模型（根据 DDD）。
例如：
与实际尝试过的人的任何链接，或者一些令人信服的 couter-arguments 为什么不能这样做？
ps：请不要回答“是的，它可以完成，因为 FSM 是图灵完备的，具有足够的内存 bla bla”
“如果你拿着锤子，一切都是钉子”
与其问是否可能，不如问： 我想以声明方式做这件事的原因是什么？
数据验证是以声明方式做的一件好事。你有一个 DTO，你添加了一些属性，一切都清晰易读。
以声明方式完成的业务流程......让我想起了 Windows Workflow Foundation 的一次重大失败。真的有人在用吗？以声明方式制作以行为为中心的组件有什么好处？命令式的方式似乎很适合这一点。决策逻辑……也许吧。但又一次 - 为什么？
“派生/计算的字段可以声明式地完成，但有点棘手” 当有一种方法可以用简单的事情实现相同的结果时，为什么你想做一些棘手的事情？
所以为什么？您是否需要通过编辑一些配置文件来更改应用程序在运行时的行为？好吧，去吧。
您是否有一个将被许多客户使用的通用域，并且您需要重新配置以适应它们？好的，但是您需要清楚地区分您的域的不变核心和变化的东西。不要试图让所有的东西都可以配置——你最终会出现内部平台综合症。
您是否相信您可以制作一种声明性语言，您的客户可以使用它来更改他的域而无需程序员？不，你会失败的。我知道一种应该是这样的语言。普通会计师用来探索数据的简单、声明性语言。它被称为 SQL :D
我完全同意 Bartłomiej Szypelow 的评论。无论如何，我会尽力回答你的问题。
声明式语言总是依赖于命令式语言才能工作。以像算术这样简单的事情为例。当我们询问结果时，1+1我们首先需要知道1应该如何理解以及在这种情况下如何+计算运算符，然后才能解释整个语句。这是我们能够克服复杂性的方法之一；您无需知道如何进行加号操作即可使用加号。
来自http://en.wikipedia.org/wiki/Imperative_programming：
过程式编程可以被认为是向声明式编程迈出的一步。程序员通常可以通过查看过程的名称、参数和返回类型（以及相关注释）来判断特定过程应该做什么，而不必查看它如何实现其结果的细节。同时，一个完整的程序仍然是必不可少的，因为它在很大程度上“修复”了要执行的语句及其执行顺序。
在任何领域都同样适用。reschedule如果你问你的乘务员，flight她知道什么是航班和乘客，以及如何使用reschedule。因此，在不描述调度如何工作的情况下创建一个完全声明性的航班调度域模型是不可能的。由于所有域模型都包含操作/行为，因此同样不可能用声明性语言创建域模型，除非您的问题域不是唯一的，例如当您有三个以类似方式运营的航空公司时。
回到为什么……你说：
实际上，假设的原因实际上是允许非编码人员通过配置创建（微不足道的）后端
声明式编程并不总是比命令式编程简单。大多数时候，人们倾向于考虑结果，但有时结果如此多样，以至于分步思考（更）简单。这就是为什么这些不同的风格存在并首先继续存在的原因。编码员和非编码员之间的主要区别不是非编码员倾向于考虑结果而不是过程，而是非编码员根本不想被计算机的工作所困扰。非编码人员希望专注于问题。根据领域的不同，非编码人员可能最好使用命令式 DSL，而不是声明式 DSL。