终于抽出时间调整了一下DDD的结构，感觉这套设计虽然有些不是很原教旨，但已经能很好的支持至少一年的业务迭代了。直接给结论，直接抄也不会有什么错。
整体方案脱胎自openai的assistant api

Entity

• Thread，对话过程。由Message构成。
• Message，单个消息或者事件。由TypedContent构成。
• TypedContent，一段特定格式的内容（e.g. 一次搜索，一个图片生成）。

VO

• Run，一次推理过程。虽然是但有ID，在推理存活过程中可以使用ID进行控制。类似于一次性的下载任务。
• Step，单次数据/操作，如果前后端都统一，每个step会带上TypedContent的id。（e.g. append text with text value）。

两个小备注

• 在实践中，这个虽然TypedContent是entity反而不适合做为一个持久化实例，只是step整合后的临时数据，因为step是有时序的，TypedContent如果有时序会和step极为相似，如果没有会丢失信息量。
• ChatGPT把这个也抽象成了Message，感觉并不合适，生命周期和真正的message并不一样。

生命周期

可以理解成Entity的状态机在事件风暴中事件的驱动下进行流转。对于后端来讲，是precondition；对于前端来讲，是VM做数据转换时非常重要的输入。生命周期很容易被以各种数据特征来判断，比如history为空的thread在初始态。这种方式很难统一理解，而且很容易出现各种bug。所以，我认为entity的生命周期是系统中几乎最重要的设计。

Thread

UserMessage

AssistantMessage