时间戳

首页 > 解决方案 > 标题、标签和其他与 UI 相关的东西是否应该包含在域模型中？

domain-driven-design - 标题、标签和其他与 UI 相关的东西是否应该包含在域模型中？

问题描述

我对如何严格处理与 UI 相关的事情感到困惑，这些事情不会在领域模型的业务逻辑中使用：如何正确地将它们存储在数据库中？

例如，如果我有一个作为实体的聚合，并且该模型的主要目的是处理重要的事情，我是否应该在模型中包含一个标题，即使它对业务逻辑没有任何贡献？如果我想将标题存储在为我的实体存储其他数据（例如重要的事情）的同一个表中，这有关系吗？

@Entity
MyAggregate:
    id: ID
    title: str
    importantThing: ImportantThing

    def doSomethingWithImportantThing():
        ...

如果我没有在模型中包含标题，那么如何使用Repository模式正确存储它？如果我将标题保留在我的模型中，我的存储库可能如下所示：

@Repository
MyAggregateRepository:

    def create(myAggregate: MyAggregate):
        ...

如果我从模型中删除标题，存储库会发生什么情况？它应该像这样转换：

@Repository
MyAggregateRepository:

    def create(myAggregate: MyAggregate, title: str):
        ...

标签： domain-driven-design

解决方案

经验法则是只保留在聚合状态中做出决策和保护不变量所必需的东西。否则，聚合会受到外来问题的污染，并转换为过度增长的数据库表或文档的混乱的一对一表示。

作为任何规则，它有例外。我认为从一开始就过火并过早拆分实体并不是一个好主意。

但是，如果您觉得事情变得一团糟，并且您可以看到一组字段在一组函数中使用的模式，而另一组字段仅在一组不同的函数中使用，您可能会认为您的聚合值得分裂。

存储库模式在很大程度上与执行命令相关。它的主要目的是处理聚合持久性。实现查询时，请考虑使用 CQRS 并编写您需要编写的查询，它不必是处理查询的存储库。查询也是幂等的并且没有副作用（性能除外），因此在编写查询时不要考虑域模型是相当安全的。不过，最好使用通用语言来命名您的查询。

推荐阅读