可能的声明性域模型（DDD）？答案

【问题标题】：Declarative Domain Model possible (DDD)?可能的声明性域模型（DDD）？
【发布时间】：2013-09-30 20:37:34
【问题描述】：

我正在寻找见解/论文/文章等，是否可以使用完全声明性域模型（根据 DDD）。

例如：

验证可以是声明性的（很多 ORM 都这样做）
业务流逻辑可以是声明性的：通过 ddd-repositories 最有可能在 Crud 操作上使用 DSL 来定义工作流/有限状态机/流程管理器/DDD Saga（随便你怎么称呼它）
决策逻辑可以是声明性的。即：大多数情况下，这归结为简单的条件
派生/计算字段可以以声明方式完成，但有点棘手，尤其是在级联时。即：您必须在计算字段上保留依赖关系图等。仍然可以做到。

任何与实际尝试过的人的链接，或者一些令人信服的 couter-arguments 为什么不能这样做？

p.s.：请不要回答“是的，它可以完成，因为 FSM 是图灵完备的，具有足够的内存 bla bla”

【问题讨论】：

虽然我觉得这个想法很有趣，但我不认为 StackOverflow 是为这种讨论风格而设计的（无论是直接关于优缺点，还是外部资源列表）。跨度>
programmers.stackexchange.com 会更好吗？
来自程序员堆栈交换"What type of questions should I avoid asking" 页面：If your motivation for asking the question is “I would like to participate in a discussion about ______”, then you should not be asking here. However, if your motivation is “I would like others to explain ______ to me”, then you are probably OK。在我看来，您的问题更像是前者，因此也不会成为 Programmers 的主题。
好吧，我正在征求专家意见（将我放在后者中），但我自己对此并不完全赞同，这可能导致我不会把所说的一切都当真。这是否一定会引起讨论还有待商榷（双关语）。我会在那里试试。谢谢。
我在dsl-platform.com 上看到了这种精神，虽然我不确定自己是否愿意使用这样的框架......

标签： domain-driven-design declarative domain-model saga

【解决方案1】：

“如果你拿着锤子，一切都是钉子”

与其问是否可能，不如问： 我想要以声明方式执行此特定操作的原因是什么？

数据验证是一个很好的声明方式。你有一个 DTO，你添加了一些属性，一切都清晰易读。

以声明方式完成的业务流程...让我想起了 Windows Workflow Foundation 的一次重大失败。真的有人在用吗？以声明方式制作以行为为中心的组件有什么好处？命令式的方式似乎很适合这一点。决策逻辑……也许吧。但又一次 - 为什么？

“派生/计算字段可以声明式完成，但有点棘手” 既然有办法用简单的事情达到同样的结果，为什么还要去做棘手的事情？

那为什么？您是否需要通过编辑一些配置文件来更改应用程序在运行时的行为？好的，加油。

您是否有一个可供许多客户使用的通用域，并且您需要重新配置以适应它们？好的，但是您需要清楚地区分您的域的不变核心和变化的东西。不要试图让所有东西都可配置——你最终会得到Inner Platform syndrome。

您是否相信您可以制作一种声明性语言，您的客户可以使用它来更改他的域而无需程序员？不，你会失败的。我知道一种应该是这样的语言。普通会计师用来探索数据的简单、声明性语言。它被称为 SQL :D

【讨论】：

嘿嘿好的点。实际上，假设的原因实际上是允许非编码人员通过配置创建一个（微不足道的）后端。
根据我的经验 - 非编码人员甚至无法用小黄瓜语法编写正确的场景。他们可以阅读它们，验证它是否是他们想要的。但是写？他们这样做。然后我解决了这个废话......
将代码理解为数据对于单一实现业务规则很有价值，这些规则可以跨多个平台动态实现，并评估与特定数据更改相关的适用性（否则绕过，尤其是在必要的数据时已知在本地不可用）。

【解决方案2】：

我完全同意 Bartłomiej Szypelow 的评论。无论如何，我会尽力回答你的问题。

声明式语言始终依赖于命令式语言才能工作。以像算术这样简单的事情为例。当我们询问1+1 的结果时，我们首先需要知道应该如何理解1，以及在这种情况下如何计算+ 运算符，然后才能解释整个语句。这是我们能够克服复杂性的方法之一；您无需知道如何进行加号操作即可使用加号。

来自http://en.wikipedia.org/wiki/Imperative_programming：

过程式编程可以被认为是向声明式迈进的一步编程。程序员通常可以通过查看过程的名称、参数和返回类型（以及相关的 cmets)，一个特定的程序应该做什么，没有必须查看它如何实现其结果的细节。在同时，一个完整的程序仍然是必要的，因为它“修复” 要执行的语句及其执行顺序范围。

在任何领域都同样适用。如果你问空姐reschedule你的flight，她知道什么是航班和乘客以及如何reschedule一个。因此，在不描述调度如何工作的情况下创建一个完全声明性的航班调度域模型是不可能的。由于所有领域模型都包含操作/行为，因此同样不可能以声明性语言创建领域模型，除非您的问题领域不是唯一的，例如当您有三个以类似方式运营的航空公司时。

回到为什么……你说：

实际上，假设的原因实际上是允许非编码人员通过配置创建一个（微不足道的）后端

声明式编程并不总是比命令式编程简单。大多数时候，人们倾向于考虑结果，但有时结果是如此多样，以至于分步思考（更）简单。这就是为什么这些不同的风格存在并继续存在的原因。编码人员和非编码人员之间的主要区别不是非编码人员倾向于根据结果而不是过程来思考，但非编码人员根本不想被打扰计算机的工作原理。非编码人员希望专注于问题。根据领域的不同，非编码人员可能最好使用命令式 DSL，而不是声明式 DSL。

【讨论】：