domain-driven-design - 声明域模型可能(DDD)？

Question

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

例如:

验证可以是声明性的(很多 ORM 都这样做)

业务流逻辑可以是声明性的:有一个 DSL 用于在 Crud-operations 上定义工作流/有限状态机/流程管理器/DDD Saga(无论你想叫它什么)，最有可能是通过 ddd-repositories

决策逻辑可以是声明性的。即:大部分时间这归结为简单的条件

派生/计算字段可以声明性地完成，但有点棘手，尤其是在这种级联时。即:您必须在计算字段等上保留依赖关系图。仍然可以完成。

任何实际尝试过的人的链接，或者一些令人信服的反驳论据，为什么不能这样做？

ps:请不要回答“是的，它可以做到，因为 FSM 是图灵完备的，具有足够的内存 bla bla”

Answer 1

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

而不是问是否有可能 - 问:
我想以声明方式做这件事的原因是什么？

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

业务流程以声明方式完成...类似于 Windows Workflow Foundation 的一个巨大失败。真的有人在用吗？
以声明方式制作以行为为中心的组件有什么好处？命令式方式似乎非常适合这一点。
决策逻辑……也许吧。但是再次 - 为什么？

“派生/计算字段可以声明性地完成，但有点棘手”
当有一种方法可以用简单的事情达到相同的结果时，为什么你想做棘手的事情？

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

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

你相信你可以制作一种声明性语言，你的客户可以在不需要程序员的情况下改变他的领域吗？不，你会失败。我知道一种应该是这样的语言。一种简单的声明性语言，普通会计师会用来探索他们的数据。它被称为 SQL :D