【发布时间】：2012-08-10 17:08:42
【问题描述】：
我正在学习领域驱动设计 (DDD) 技术，但我觉得我还没有很好地理解它。
DDD 建议将业务逻辑（不是基础设施，如持久性、安全性等）放入域对象、持久性存储库、为客户端（演示）组装域对象的聚合器、域对象之上的薄层服务和存储库、聚合器并充当事务边界。
让我这样说：
在 DDD 中，ViewController --> SomeService --> {Domain Objects, Repositories, Aggregators}
在我目前的（程序风格）方法中： ViewController --> SomeService --> DAO/Repository
这里，ViewController 与一个或多个服务对话，以使用 DAO 从/向数据库拉取/推送数据。如果仅对域对象的属性进行操作的任何业务逻辑将在该域对象本身的方法中。最后，从服务中获取的数据被聚合到 DTO 中以呈现在视图层中。
所以对我来说这两种方法看起来几乎相似。
谁能解释一下我错过了什么？
PS：我正在添加更多信息以更好地解释我的问题。 理论上每个人都在说 DDD 建议“逻辑应该在域对象中”。好的。 让我们来看一个真实的场景。
在 ShoppingCart 应用程序中，一些用户下了订单。要处理订单，我需要执行以下所有子任务：
获取每个项目的详细信息并计算总订单价格。
获取收货地址并使用地址验证服务进行验证
验证/验证信用卡详细信息
将所有订单相关信息保存到数据库中
所以按照DDD我会放逻辑，
Order 对象中的Order Total 计算，该对象循环遍历其List 对象。
在地址对象中，我将拥有 validate() 方法，该方法会调用一些 BING 地址验证。
在 CreditCard 类中，我将拥有 authorize() 方法，该方法调用一些 CCAuthorizationService 来授权使用一些第三方服务。
使用一些存储库将所有订单内容保存到数据库中。
所有这些步骤都将通过调用 Order.process() 来触发
如果这是正确的 DDD 方法？如果是，我们的域对象直接与存储库交互，这似乎违反了关注点分离。
如果这不是正确的 DDD 方法，有人可以告诉我你是如何为上述用例设计的吗？
【问题讨论】：
-
“仅对域对象的属性进行操作的业务逻辑”是什么意思？您可能缺少 IMO 的是，您当前的方法并不完全是通常所说的程序代码......
-
我的意思是，如果有任何计算可以得出仅基于一个域对象的属性的某个值，那么执行计算的方法应该只在域对象中，而不是在服务类中。
标签： java oop domain-driven-design ooad