我正在寻找洞察力/论文/文章等，是否可以使用完全声明性域模型（根据DDD）。
例如：
任何实际尝试过的人的链接，或一些令人信服的争论 - 为什么不能这样做？
p.s。：请不要回答“是的，可以这样做，因为FSM是Turing-complete，有足够的内存bla bla”
答案 0 :(得分：6)
“如果你拿锤子，一切都是钉子”
不要问是否可能 - 请问： 我想以声明方式做这件事的原因是什么？
以声明方式进行数据验证是一件好事。你有一个DTO，你添加一些属性，一切都清晰可读。
业务流程以声明方式完成...让我感到非常麻烦的是Windows Workflow Foundation。是否有人正在使用它？ 以声明方式创建以行为为中心的组件有什么好处？势在必行的方式似乎很适合这一点。 决策逻辑......也许吧。但又 - 为什么？
“派生/计算字段可以以声明方式完成，但有点棘手” 当有一种方法可以用简单的方法达到相同的结果时，你为什么要做一些棘手的事情呢？
那么？ 您是否需要通过编辑某个配置文件来更改运行时应用程序的行为？好的，去吧。
您是否拥有将被许多客户端使用的通用域，您需要进行一些重新配置以适应它们？好的，但是您需要清楚地区分域中不可更改的核心和不同的东西。不要试图让所有事情都可配置 - 你最终会得到Inner Platform syndrome。
您是否相信您可以制作一种声明性语言，客户可以使用该语言来更改其域名而无需程序员？不，你会失败的。我知道一种应该是这样的语言。普通会计师用来探索数据的简单的声明性语言。它叫做SQL：D
答案 1 :(得分：2)
我完全同意BartłomiejSzypelow的话。无论如何，我会尽力回答你的问题。
声明性语言总是依赖于命令式语言才能发挥作用。拿一些像算术一样简单的东西。当我们要求1+1的结果时，我们首先需要知道应该如何理解1以及在该上下文中如何在整个陈述之前计算+运算符解释。这是我们克服复杂性的方法之一;你不需要知道如何使用plus操作。
来自http://en.wikipedia.org/wiki/Imperative_programming：
程序编程可以被视为迈向声明的一步 节目。程序员通常可以简单地通过查看 程序的名称，参数和返回类型（以及相关的 评论），一个特定的程序应该做什么，没有 必须查看它如何实现其结果的细节。在 同时，一个完整的程序仍然是必不可少的，因为它'修复' 要执行的语句及其执行顺序 程度。
在任何领域同样适用。如果您向乘务员询问reschedule flight你的reschedule她知道什么是飞机和乘客，以及如何{{1}}。因此，创建完全声明性的航班调度域模型而不描述调度如何工作是不可能的。由于所有域模型都包含操作/行为，因此以声明性语言创建域模型同样是不可能的，除非您的问题域不是唯一的，例如当您有三家以类似方式运营的航空公司时。
回到原因......你说：
实际上，假设的原因实际上是允许非编码人员 通过配置创建一个（普通的）后端
声明性编程并不总是比命令式编程简单。大多数时候人们倾向于在结果中思考，但有时候结果变化很大，以至于（步骤）思考更简单。这就是为什么这些不同的风格存在并且首先继续存在的原因。编码器和非编码器之间的主要区别在于 not 非编码器倾向于根据结果而不是过程进行思考，但是非编码器根本不想被打扰计算机的工作原理。非编码人员希望专注于这个问题。根据域，非编码器可以通过命令式DSL而不是声明性DSL来获得最佳帮助。