DDD：无处不在的语言与发表语言
以最短的方式问这个问题：它们会有所不同吗？
背景：弗拉德·霍诺夫（Vlad Khononov）在他的出色著作《学习域驱动设计》（2021）中写道（p55）：
供应商的公共界面不符合其范围 无处不在的语言。相反，它旨在公开协议 以集成为导向的消费者方便 语言。
从某种意义上说，开放式服务模式是反腐败层模式的逆转：供应商实施的代替消费者而不是消费者 其内部模型的翻译。
而Olaf Zimmerman在一篇很棒的文章（2021）中（ https://eprints.cs.univie.ac.at/6948/1/europlop21-s16-camera-ready2.pdf ）写道：
，但是为了使API对域专家可以理解，这是 重要的是，API中的名称和抽象遵循术语 用Ubiqitous语言定义，该语言正式指定 域模型。
我认为要提出质疑的Anwer是肯定的：可以在同一域元素中使用出版的语言和无处不在的语言中使用不同的术语。在域模型中，您可以通过应用“别名”来注册不同的术语：一个别名表示域模型中用于元素的已发表语言术语，该术语是根据相关有限上下文的无处不在语言命名的。
你怎么认为？
To ask this question in the shortest way possible: can they be different?
Background: Vlad Khononov in his excellent book 'Learning Domain-Driven Design (2021)' writes (p55):
The supplier's public interface is not intended to conform to its
ubiquitous language. Instead, it is intended to expose a protocol
convenient for the consumers, expressed in an integration-oriented
language.In a sense, the open-host service pattern is a reversal of the anticorruption layer pattern: instead of the consumer, the supplier implements
the translation of its internal model.
Whereas, Olaf Zimmerman in a great article (2021) (https://eprints.cs.univie.ac.at/6948/1/europlop21-s16-camera-ready2.pdf) writes:
But in order to make the API understandable to domain experts, it is
essential that names and abstractions in the API follow the terms
defined in the ubiqitous language which is formally specified by the
domain model.
I think the anwer to question would be YES: it's possible to use different terms in published language and ubiquitous language for the same domain element. In the domain model you register the different terminology by applying 'aliases': an alias denotes the published language term used for an element in the domain model which is named according the ubiquitous language of the corresponsing bounded context.
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
普遍存在的语言
已发布的语言
Ubiquitous language
Published language
问题是DEV（内部和外部）需要进行多少翻译，在API中的术语与UL中的单词之间需要做多少。它几乎总是一个权衡，随着产品及其API的发展，它会随着时间而变化。
所有这些模式在其方式上都是可以接受和有效的：
通过管理外部API的 意味着如果您发现术语发生变化，则意味着更少的蠕动空间。方法3没有试图保留术语，而是可以帮助您改善内部UL，同时仍保护API神圣。
您可以从默认情况下从方法2开始，然后努力保留它，但要以外部输入和开关方法为指导。
The question is how much translation do Devs (internal and external) need to do between terms in the API vs. words in UL. It is almost always a trade-off, one that is shaped over time as the product and its API evolve.
All these patterns are acceptable and effective in their way:
Managing an external API means less wriggle room if you uncover terminology changes. Instead of trying to retain terms as-is, Approach 3 helps you improve the internal UL while still protecting the API sanctity.
You can start with Approach 2 by default and strive to retain it, but be open to being guided by external input and switch approaches.