0

我正在学习领域驱动设计（DDD）技术，我觉得我还没有很好地理解它。

DDD 建议将业务逻辑（不是基础设施，如持久性、安全性等）放入域对象、持久性存储库、为客户端（演示）组装域对象的聚合器、域对象和存储库之上的薄层服务、聚合器并充当事务边界。

让我这样说：

在 DDD 中，ViewController --> SomeService --> {Domain Objects, Repositories, Aggregators}

在我当前的（程序风格）方法中：ViewController --> SomeService --> DAO/Repository

在这里，ViewController 与一个或多个服务对话，以使用 DAO 从/向数据库拉取/推送数据。如果仅对域对象的属性进行操作的任何业务逻辑将在该域对象本身的方法中。最后，从服务获得的数据被聚合到 DTO 中，以呈现在视图层中。

所以对我来说，这两种方法看起来都差不多。

有人可以解释一下我错过了什么吗？

PS：我正在添加更多信息以更好地解释我的问题。理论上每个人都在说 DDD 建议“逻辑应该在域对象中”。好的。让我们来看一个真实的场景。

在 ShoppingCart 应用程序中，一些用户下了订单。要处理订单，我需要执行以下所有子任务：

  1. 获取每个项目的详细信息并计算总订单价格。

  2. 获取收货地址并使用一些地址验证服务对其进行验证

  3. 验证/验证信用卡详细信息

  4. 将所有订单相关信息保存到数据库中

因此，通过遵循 DDD，我将提出逻辑，

  1. Order 对象中的 Order Total 计算，该对象循环遍历其 List 对象。

  2. 在地址对象中，我将拥有调用一些 BING 地址验证的 validate() 方法。

  3. 在 CreditCard 类中，我将拥有 authorize() 方法，该方法调用一些 CCAuthorizationService 来授权使用一些第三方服务。

  4. 使用一些存储库将所有订单内容保存到数据库中。

所有这些步骤都将通过调用 Order.process() 来触发

如果这是正确的 DDD 方法？如果是这样，我们的域对象直接与存储库交互，这似乎违反了关注点分离。

如果这不是正确的 DDD 方法，有人可以告诉我您如何为上述用例设计吗？

4

4 回答 4

1

它归结为逻辑所在的地方。在 DDD 中，逻辑主要进入模型层，因此它靠近数据。在过程代码中，逻辑进入事务层，因此它与数据分离。Fowler 有一个很好的描述，你可以在这里阅读。

于 2012-08-10T17:33:13.237 回答
1

DDD 是独立于语言的，它是关于通过专家理解领域并构建一种通用语言，您可以使用它来讨论该领域。因此它不能直接与函数式、过程式或面向对象的编程语言进行比较，因为它们没有可比性。

视图控制器是特定于 MVC 框架的，而不是特定于 DDD。

在 MVC 中，为视图准备数据的 DTO 是视图模型。

希望有些帮助。

于 2012-08-13T08:02:57.813 回答
0

它们是相似的。

希望您实际上是在将“OOP”与“DDD”进行比较。DDD 是 OOP (IMO) 的子集，或者至少应该在 OOPL 中。DDD 是一种分解职责的特定思维方式。

于 2012-08-10T17:22:19.920 回答
0

这与技术或 OOP 或类似的东西无关。它是关于关注手头的领域、领域专家使用的语言、理解领域并对该领域进行建模，以便在代码中出现重要的概念。

它最初是使用 OOP 完成的，许多人声称它只能使用 OOP 完成。然而，最近像 Greg Young 这样的人已经展示了如何在函数式语言中进行 DDD，并且仍然专注于该领域。

程序代码倾向于忽略所有这些，只关注如何从任何数据源读取/写入数据。例如，与像 Movex 这样的系统集成时，将有十亿个表和列的名称完全滞后，例如 TAXEM.YAROOD FOOB.AAR，这对任何阅读该代码的人来说都毫无意义......

于 2012-08-13T07:39:20.990 回答