考虑是否存在要为其创建有界上下文的域。但是，不应在该域中保留任何内容。应该只有一个纯粹基于任务的逻辑，并且不会更新假设的领域模型。
我看不出在这样的领域中应用实体模式的方法，在这种情况下，我脑海中只有服务和价值对象。我现在想知道，以下哪一种说法是正确的：
- 这是DDD不应该应用于的子域
- 问题出在战略设计上，这样的子域永远不应该被提取为一个单独的有界上下文
- 创建一个只包含服务和价值对象的域模型是可以的
根据我的经验，DDD有两个误解。
a) 没有"我做DDD"one_answers"我不做DDD。我们总是处于两者之间，没有非黑即白。这就像敏捷开发。DDD是一种为您的业务(或技术)domain构建域模型的方法。
b) DDD实体与@Entity注释无关。DDD实体是可识别的(仍然没有@Id注释！)。并且不能通过它的所有属性来识别，而是通过它在存储库中的存在来识别。
我不知道你的问题空间是什么。但假设你正在构建一个GUI。GUI将不会被持久化。但仍然有类似实体的元素(比如窗口可能是聚合根)，UI组件肯定是该域中的实体。您可能会实现聚合将确保的不变量。您可能会有一些存储库，可以要求它们返回对UI组件的引用。
没有持久状态并不意味着不能应用DDD模式。