Java 过程代码和领域驱动的设计风格代码之间有什么区别？

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

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

让我这样说：

在DDD中，ViewController-->SomeService-->{域对象、存储库、聚合器}

在我当前的（程序式）方法中： ViewController-->SomeService-->DAO/存储库

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

所以在我看来，这两种方法几乎是相似的

有人能解释一下我错过了什么吗

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

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

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

获取传递地址并使用一些地址验证服务进行验证

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

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

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

Order对象中的Order Total计算，该对象在其列表对象中循环

在Address对象中，我将使用validate（）方法调用一些BING地址验证

在CreditCard类中，我将有authorize（）方法，该方法调用某些CCAuthorizationService以使用某些第三方服务进行授权

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

所有这些步骤都将通过调用Order.process（）触发

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

如果这不是正确的DDD方法，请告诉我您如何为上述用例进行设计？

它们是相似的

---

希望您实际上是在比较“OOP”和“DDD”。DDD是OOP（IMO）的一个子集，或者至少应该在OOPL中。DDD是一种分解责任的具体思维方式。

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

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

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

---

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

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

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

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

---

希望这能有所帮助。

您所说的“仅对域对象的属性进行操作的业务逻辑”是什么意思？IMO可能缺少的是，您当前的方法并不完全是通常所说的过程代码……我的意思是，如果有任何计算只基于一个域对象的属性来导出某些值，那么执行计算的方法应该只在域对象中，而不是在服务类中。Adrian，你是对的。DDD是独立于语言的。我期待着通过遵循DDD方法实现解决方案。最后，我们需要将这个DDD概念转换成正确的代码。你能告诉我你是如何处理上述DDD风格的ShoppingCart场景的吗？我会将你的信用卡授权放入一个服务中，因为它将涉及多个域对象的合作，可能还包括工作流类型流和决策。你的前两个项目不需要任何存储库访问。我希望创建对象最有可能是某种工厂，“保存”方面是您可以在域实体/对象中执行的操作。在体系结构上，您最好使用IOC容器在构造函数中通过接口注入存储库。因此，如果任务涉及流程的工作流样式，并且涉及多个域对象的协作，那么您更愿意将此工作流放在服务中。在这种情况下，似乎DDD=正确编写的过程式方法，域对象具有对自身属性进行操作的业务逻辑方法。休息是一样的