领域驱动设计(DDD)：领域或基础设施的关注点

Question

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

描述域的简化示例：

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

“用户希望检查网页并确定短语"lorem”是否出现以及在哪个位置出现。“

我们将使用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，不再是一个纯对象(POCO、POJO等)。在DDD的时候我觉得这不对。

我的理解是selenium表达式也不属于Application层，因为这会使类/方法臃肿，而且理想情况下服务层应该很薄。

那么这是否属于基础设施层呢？就像有持久性代码的存储库一样。类似于：

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

在HTML中搜索字符串不是业务逻辑，因此域驱动设计不适用于这里。

DTO或没有表示页面行为的类在这里是有意义的。

如果需要对硒特定的实现或跨应用程序的可重用性进行抽象，“搜索服务”将是一个基础设施问题。如果不需要这样做，它将是一个特定于应用程序的服务/实用程序。

Answer 2

我的理解是selenium表达式也不属于Application层，因为这会使类/方法臃肿，而且理想情况下服务层应该很薄。

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

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

如果域是贫血(请阅读‘简单’)，那么模型也将贫血。

贫血有一个意义，当我们考虑应用程序的写部分时，当行为停留在域服务中时，它应该停留在聚合中。

如果是这样的话，这个实体还需要吗？

如果你的东西有一个生命周期(它有一个身份，它被创建，修改，然后死亡)，那么是的，一个实体是必要的。如果缺少行为(因为域很简单)，您可以有一个CRUD实体，而不是一个完整的DDD聚合。您可以采取其他战略或战术DDD决策(如有限上下文和上下文映射)。

应用服务层是否可以直接调用基础结构层并执行一些操作(执行用例)而不需要任何实体(因此也包括域)的参与？

是。