1

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

描述域的简化示例：

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

“用户想要检查网页并确定短语“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 的新手）我完全脱离了基础，在这种情况下，非常欢迎任何建议或建议。

谢谢

4

2 回答 2

1

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

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

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

如果域是贫血的（请阅读“简单”），那么模型也将是贫血的。

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

如果是这样，这个实体是否还有必要？

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

应用程序服务层是否可以直接调用基础设施层并执行一些操作（执行用例）而不涉及任何实体（以及域）？

是的。

于 2018-01-25T07:56:54.933 回答
0

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

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

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

于 2018-01-25T15:11:33.990 回答