了解DTO和贫血领域模型

Question

我是Domain Pattern的新手，我需要确保我理解到目前为止我读过的内容!! 请告诉我以下句子是否属实或是否违反了与DDD相关的原则

0）DAL将在DTO中接收参数并在DTO（实体）的LIST中返回获取的数据

1）通过存储库模式解析BLL和DAL。

2）实体是DTO对象。

3）ProductCategoryData包含ProductData列表。

4）如果BLL.ProductCategory不包含描述业务对象的属性，那么它将是Anemic Domain Model ANTI Pattern。

5）BLL.ProductCategory包含BLL.Product的列表......我对此感觉不好

6）我避免在那个设计贫血领域模型反模式。

7）我成功应用了域模型模式。

8）我使用DTO对象在层之间传输数据。

请跟我说说:)

Answer 1

你为什么感觉不好？贫血听起来像一个坏词，但你有什么害处？

我看到的物体没有任何贫血行为。我不是由数据成员判断的。

如果您选择其他原因将该行为转移到其他地方（例如服务），那么您可能会选择一种比面向对象更具功能性的架构。这真的很糟糕吗？

我认为像贫血这样的标签听起来很糟糕，但它们只是描述了一个人的设计决定。它也可能揭示某人的OOP偏见。 OOP从业者会认为功能语言是贫血的，但并不一定是致命的。

更好的问题是：“我是否有并行模型？一个用于DTO，另一个用于业务层？”如果是的话，我会说双重维护比贫血症更有害。

Answer 2

如果那是界面，你的对象上没有方法，那么这仍然是一个贫血模型。

存储库应与模型的聚合关联。 我的模型只包含那些实体然后并不重要设计是多么糟糕或好 因为整体复杂性会很低。

同时为您的模型选择更好的名称，并避免使用“数据”之类的通用名称。 读者立即问：什么样的数据？