python - 领域驱动设计(DDD): A Domain or Infrastructure Concern

Question

我正在沉浸在 DDD 中，并且有一个关于什么属于该域以及什么是基础设施问题的问题。

描述域的简化示例:

应用程序中的上下文之一是关于允许用户检查网页以获取某些信息的便利功能。即..

“用户想要检查网页并确定短语“lorem ipsum”是否出现以及出现在什么位置。”

我们将使用 Selenium 作为匹配短语的底层技术。

在深入研究 DDD 之前，我会创建一个如下所示的类(下面是 Python，但语言不重要):

class Page:
def __init__(self, url, environment, driver):
    self.environment = environment
    self.url = url
    self.driver = driver    // Selenium Driver


def contains_phrase(self, phrase):
    self.driver.get(self.environment.url + self.url_suffix)  // Selenium Command
    ...

该实体现在依赖于 selenium，并且不再是纯对象(PO​​CO、POJO 等)。我在 DDD 中感觉这不正确。

我的理解是，selenium 表达式也不属于应用程序服务层，因为这会使类/方法膨胀，并且服务层理想情况下应该很薄。

这属于基础设施层吗？很像一个存储库，里面有持久性代码。像这样的东西:

class PageAutomator:
...
def does_page_contain_phrase(self, page, phrase):
    self.driver.get(self.environment.url + self.url_suffix)  // Selenium Command

这听起来是正确的方向吗？如果是这样？:

这意味着Page实体开始趋向于贫血模型，并且正在变成一个简单的DTO。如果是这样，这个实体还有必要吗？

应用服务层直接调用基础设施层并执行某些操作(执行用例)而不涉及任何实体(以及域)是否可以接受？即使采用更多的事务脚本方法，我的理解是 Selenium 功能仍然不应该存在于域中？

或者(我是 DDD 的新手)我完全偏离了基地，在这种情况下，非常欢迎任何建议或建议。

谢谢

Answer 1

My understanding is that the the selenium expressions also don't belong in the Application Service layer, as this would bloat the class / method and the service layer should ideally be thin.

是的，你是对的。 Selenium 表达式应该保留在基础设施内，因为它们是特定于技术的。

This means the Page entity is starting to tend towards an anaemic model, and is becoming a simple DTO. If so is this entity even necessary any more?

如果域贫乏(请阅读“简单”)，那么模型也将贫乏。

当我们考虑应用程序的写入部分时，贫血是有意义的，当行为应该保留在聚合内部时，却保留在域服务中。

If so is this entity even necessary any more?

如果您的事物有生命周期(它有一个身份；它被创建、修改，然后消亡)，那么是的，一个实体是必要的。如果行为缺失(因为域很简单)，您可能拥有一个 CRUD 实体，而不是一个成熟的 DDD 聚合。您可以采取其他战略或战术 DDD 决策(例如有界上下文和上下文映射)。

Is it acceptable for the Application Service layer to call the Infrastructure layer directly and perform some action (to perform a use case) without the involvement of any entities (and hence the domain) at all?

是的。