我最近得到了一本Scott Miller和Nick Tune合著的《领域驱动设计的模式、原则和实践》。它有一些很好的c#示例，所以与我之前读过的其他Java DDD书籍有点不同。由于c#对委托和事件的支持，Domain事件的实现非常简洁。
然而，有一件事让我担心，正如书中在应用程序服务一章中所述，它应该是"过程化的风格和精简的"。我理解应用层应该是薄的，但为什么是过程式的呢?我不想编写过程代码，否则我一开始就不会选择DDD。我还发现这篇stackoverflow文章也将应用程序服务标记为过程代码:
https://softwareengineering.stackexchange.com/questions/279369/conceptual-mismatch-between-ddd-application-services-and-rest-api所以你看到了吗?应用程序服务在风格上是过程的，而不是面向对象的。这让我想知道我是否可以通过用OO接口取代应用程序服务的过程接口来改进设计，使其更加面向对象。本文建议使用方法对象，那么它是否有效呢?除了过程应用程序服务之外，还有哪些面向对象的选择?有人能详细说明一下吗?
http://ayende.com/blog/2145/entities-services-and-what-goes-between-them应用程序服务不是编程范式意义上的过程性服务。它是一个对象，封装了数据(对其合作者对象的引用)和行为——协调对这些合作者的调用。
它可能看起来是程序性的，因为有一系列的操作，但是当有一个应用任务意味着许多步骤时，例如:
- 从存储库获取域对象
- 调用该对象的方法
- 保存对象
你无法逃避过程/顺序的本质，不管编程范例是什么。
即使你使用面向对象的责任链模式，例如，每个步骤都由链中的一个独立参与者执行，你仍然需要有一个"主"对象，它知道如何以正确的顺序组装链，因此根据定义知道过程，所以它同样是过程的。
OO世界中的所有方法都是过程的:)
我认为作者试图传达的是应用程序服务是作为操作脚本实现的。因此，它只是将域和各种其他基础设施作为一组顺序调用进行协调。理想情况下，事务边界也在应用服务层中处理。
也许Martin Fowler的服务层文章会提供更多信息。
你可能会混淆结构化编程和过程代码:)