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

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

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

例如:

  • 验证可以是声明性的(很多 ORM 都这样做)
  • 业务流逻辑可以是声明性的:有一个 DSL 用于在 Crud-operations 上定义工作流/有限状态机/流程管理器/DDD Saga(无论你想叫它什么),最有可能是通过 ddd-repositories
  • 决策逻辑可以是声明性的。即:大部分时间这归结为简单的条件
  • 派生/计算字段可以声明性地完成,但有点棘手,尤其是在这种级联时。即:您必须在计算字段等上保留依赖关系图。仍然可以完成。

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

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

    最佳答案

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

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

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

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

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

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

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

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

    关于domain-driven-design - 声明域模型可能(DDD)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19103371/

    相关文章:

    primary-key - 在我的域模型类中使用无意义的键是不是很糟糕?

    grails - 如何在 Grails 中拆分域逻辑和数据访问

    c# - 域实体应该作为接口(interface)还是作为普通对象公开?

    design-patterns - 让域对象了解数据访问层是不正确的吗?

    c++ - 关于 C++ 中的声明式编程

    python - SQLAlchemy 声明性语法中具有抽象基的多态多对多关系

    uml - "Domain Model"中的域是什么意思?

    domain-driven-design - 领域驱动设计和领域事件

    loops - 结果后的 Prolog 循环

    UML类图: Keep history of instance of class