domain-driven-design - 如何在没有显式域模型的情况下将 DDD 应用于上下文

Question

考虑有一个要为其创建有界上下文的域。但是，不应在此域中保留任何内容。应该只存在纯粹的基于任务的逻辑，并且不会更新假设的域模型。

我看不到在这样的领域中应用实体模式的方法，在这种情况下我只想到服务和价值对象。我现在想知道，以下哪一项陈述是正确的：

1. 这是不应该应用 DDD 的子域
2. 问题在于战略设计，永远不应该将此类子域提取为单独的有界上下文
3. 可以只使用服务和值对象创建域模型

Answer 1

根据我的经验，关于 DDD 有两个误解。

a) 没有“我做 DDD”和“我不做 DDD”。我们总是介于两者之间，没有黑白之分。这就像敏捷开发。您可以做一些并从中受益。DDD 是一种为您的业务（或技术）领域构建领域模型的方法。

b) DDD Entity 与@Entity 注解无关。DDD 实体是可识别的（仍然没有@Id 注释！）。并且不能通过它的所有属性来识别，而是通过它的存在来识别，例如在存储库中。

我不知道你的问题空间是什么。但是，假设您正在构建一个 GUI。GUI 不会被持久化。但是你仍然有一些类似于实体的元素（比如一个窗口可能是一个聚合根），并且 UI 组件肯定是该域中的实体。您可能会实现您的聚合将确保的不变量。您可能拥有可以要求返回对 UI 组件的引用的存储库。

仅仅因为您没有持久状态并不意味着您不能应用 DDD 模式。