领域模型是否需纳入UI相关内容？数据库存储及仓储模式咨询

我来帮你理清这个DDD实践里常见的困惑——纯UI相关的属性到底该怎么和领域模型、仓储配合处理，咱们一步步拆解：

核心判断：这个UI属性属于领域模型吗？ #

首先得明确一个关键标准：这个属性是否参与业务逻辑或业务规则。

• 如果你的title完全只是给UI展示用，既不影响doSomethingWithImportantThing()这类业务方法的执行，也没有任何业务规则依赖它（比如“标题不能为空”只是UI层面的校验，而非业务要求的必填项），那它确实不属于领域模型的范畴，本质是UI层的展示元数据。
• 但如果有业务规则绑定它（比如“聚合根必须填写标题才能触发归档流程”），那它就得留在聚合根里——因为这是业务约束的一部分，属于领域模型的核心内容。

情况1：把title留在聚合根里的处理 #

如果经过判断，title确实属于业务范畴（或者你暂时不想拆分，追求简单），那你原来的设计完全可行：

• 把title和核心业务数据存在同一张表没有任何问题，聚合根作为一个完整的业务单元，自然可以包含这类属性。
• 仓储的设计也不用调整，保持原来的样子即可，因为仓储的职责就是持久化整个聚合根：

  @Entity
  MyAggregate:
      id: ID
      title: str
      importantThing: ImportantThing
      def doSomethingWithImportantThing(): ...
  

  @Repository
  MyAggregateRepository:
      def create(myAggregate: MyAggregate): ...
  

  这种方式的优点是简单直接，不需要额外的存储逻辑；缺点是如果后续UI属性越来越多，聚合根会逐渐臃肿，偏离“专注业务核心”的定位。

情况2：把title从聚合根移除的处理 #

如果title是纯UI数据，那我们应该把它从领域模型里剥离，放在UI层或应用层的DTO中，再通过仓储妥善存储，这里有两种常用方案：

方案A：拆分存储表，单独管理UI元数据 #

• 新建一张my_aggregate_ui_metadata表，通过聚合根的id和主表关联，专门存储title这类UI相关数据。
• 仓储层面可以创建两个独立的仓储：一个负责业务聚合根的持久化，另一个负责UI元数据的存储：

  @Repository
  MyAggregateRepository:
      def create(myAggregate: MyAggregate): ...
  
  @Repository
  MyAggregateUiMetadataRepository:
      def save(aggregateId: ID, title: str): ...
  

• 应用层在创建聚合根时，先调用MyAggregateRepository.create()保存核心业务数据，再调用MyAggregateUiMetadataRepository.save()存储UI数据；读取时同理，分别获取再组装给UI展示。

方案B：同表存储，但领域模型不包含title #

• 如果不想额外建表，也可以继续把title存在同一张表，但领域模型里不包含这个属性。
• 这时候仓储的create方法需要同时接收聚合根和title，在持久化时把两者写入同一张表：

  @Repository
  MyAggregateRepository:
      def create(myAggregate: MyAggregate, title: str): ...
  

• 注意：读取时需要额外的方法获取title（比如getTitleByAggregateId(ID id): str），而且因为领域模型里没有title，业务逻辑自然不会依赖它，反而能保证领域模型的纯净性。

总结建议 #

1. 先做属性归属判断：业务相关留聚合根，纯UI数据拆出去；
2. 拆分时优先推荐单独表+单独仓储的方式，让领域模型专注于业务逻辑，边界更清晰；
3. 如果场景简单，同表不同模型的方案也可以接受，但要明确区分业务数据和UI数据的边界，避免后续混淆。

内容的提问来源于stack exchange，提问作者deemson