泛在语言在应用服务中的应用

我认为应用服务层应该尽可能多地反映UL,而不泄露领域模型技术解决方案的细节。换句话说,您希望应用程序服务公共API使用泛在语言的术语来表示,但不希望客户机代码在域模型层上耦合。

如果您使用UL词汇表命名方法args,那么您将在应用程序外部公开域对象

这是一个误解:方法参数应该使用UL术语命名,但是参数类型不应该利用域包中定义的类型。这只是出于技术原因,因为这种分离允许您独立于公共应用程序的API更改域模型。

一个例子比仅仅讨论“哲学”要好得多。但是。。

矛盾的是大多数DDD设计 不要 事实上,要严格遵守UL。例如,看看几乎所有公开的“DDD”设计 Vaughn Vernon's Github repository

服务也一样。服务是 完全是“领域”的一部分。试着告诉一个商人你已经实现了 PasswordService ,我保证一脸茫然。服务在外部也是纯技术性的,其中包含一些与业务相关的方法,这些方法实际上可能属于某个价值对象或实体。

因此,虽然我同意“哲学”部分的观点,但埃里克·埃文斯(Eric Evans)今天所定义的构建块远不是哲学的最佳实现。

请看一下我对这个问题的介绍: https://speakerdeck.com/robertbraeutigam/object-oriented-domain-driven-design