泛型语言（UL）用于整个受限上下文中，领域模型和应用程序层对吗？好。然后，应用服务的方法的名称属于UL。但是该方法的论点（不应将域对象暴露给用户）不会成为UL的术语。如果您使用UL词汇表命名方法args，那么您将在应用程序外部公开域对象。
您如何解释有关命名应用程序服务参数的矛盾？
也许这个问题似乎有点哲学性，但是DDD也是如此，它是软件开发的一种哲学，它是基于UL的。
更新
有人要求举一个例子，而不仅仅是哲学。好吧，假设我们的域名是关于一家销售产品的商店。应用程序服务的一种方法可能是：
addProductToShoppingCart（产品产品，ShoppingCart shoppingCart）；
但是Product和ShoppingCart是域模型的实体/值对象，我们不应将其公开给客户。
因此，args应该是DTO或原始类型。但是这些类型不属于UL。 Product和ShoppingCart确实属于UL，应该是该方法的args，但是这样做会违反将域暴露给客户的规则。
答案 0 :(得分：1)
我认为应用程序服务层应尽力反映UL，而不会泄漏域模型技术解决方案的细节。换句话说，您希望使用通用语言的术语来表示应用程序服务公共API，但是您不希望将客户端代码耦合在域模型层上。
“如果使用UL词汇为方法args命名，那么您将在应用程序外部公开域对象。”
这是一个误解：方法参数应该使用UL术语命名，但参数类型不应利用在域包中定义的类型。这仅出于技术原因，因为隔离使您可以独立于公共应用程序的API来更改域模型。
答案 1 :(得分：0)
一个例子比“哲学”要好得多。但是..
矛盾之处在于，大多数DDD设计实际上并不严格遵循UL。查看几乎所有公开可用的“ DDD”设计，例如Vaughn Vernon's Github repository。
“域”（即值对象和实体）通常建模为仅数据的“对象”，几乎没有业务逻辑。此处的方法名称已经离开了UL，并且纯粹在技术领域（通常是设置程序，获取程序）。
与服务相同。服务根本不是“域”的一部分。尝试告诉业务人员您已经实施了PasswordService，我保证您会一无所获。服务在外部也纯属技术，其中包含一些与业务相关的方法，这些方法实际上可能属于某个Value Object或Entity。
因此，尽管我同意“哲学”部分，但埃里克·埃文斯（Eric Evans）定义的今天所使用的构建模块远非该哲学的最佳实现。
看看我有关此问题的演示文稿：https://speakerdeck.com/robertbraeutigam/object-oriented-domain-driven-design