OHS ...打开主机服务 Open Host Service uses a standardized protocol for multiparty
integration. It employs a model of the domain for interchange between
systems, even though that model may not be used internally by those
systems. 1b) An ACL is bidirectional in that data flows in either direction -
either when you're sending a message to external service or
interpreting a message received from said service. 3b) Assuming BCs communicating with each other are part of the same
application and assuming we don't use OHS - should these BCs
communicate with each other directly ( ie. BC would call ACL, which in
turn would make a direct call to BC ) or via AL ( ie. BC would call
ACL, which would call AL, which then would make a direct call to BC )? I assume that we should also define a translation/anticorruption layer
sitting between OHS and the rest of our application? Are arguments and return values of Application services defined in
terms of application's domain model? Does BC always use Infrastructure services to call another BC ( of
course if BC is using ACL, then BC would call ACL, which in turn would
call Infrastructure layer, which would then call the other BC ),
regardless if that other BC is external or part of the same
application? If the latter, in 4b) you said OHS itself also acts as a translator,
which suggests that ACL used by our BC for calling external systems
won't also be used when external systems call our BC, which would
imply that ACL can't be bidirectional? c) If internal BCs do share the same AL, doesn't this mean that we may
be forced to define some Application services whose only purpose is to
enable internal BCs to communicate with each other ( thus external
clientsare not meant to call these particular Application services ).
As such, don't these Application services expose inner functionality
to external clients? Shouldn't ACL be applied only when there's a danger of the outside
model leaking into our model? Assuming BCs communicating with each other are part of the same
application and assuming we don't use OHS - should these BCs
communicate with each other directly ( ie. BC would call ACL, which in
turn would make a direct call to BC ) or via AL ( ie. BC would call
ACL, which would call AL, which then would make a direct call to BC )? I assume OHS doesn't replace AL, but instead sits on top of
Application services/AL? Since our OHS has it's very own model ( which is usually based on Core
Domain, whatever that may be ), I assume that we should also define a
translation/anticorruption layer sitting between OHS and the rest of
our application?
AL ...应用层
ACL ...反腐败层
BC ...有界上下文
1.
当我们的 OHS的公共(public)接口(interface)只能由外部BC调用ozt_strong我们的系统，但是不能被我们的 BC用来调用外部系统时，我将在这里使用术语单向。
同样，当外部BC可以使用我们的 OHS的公共(public)接口(interface)来调用我们的系统时，我将使用术语双向，但也可以由我们的 BC 使用它来调用外部系统
a) OHS 是单向的还是双向的？我会说它只能是单向的？
b)同样， AL是是单向的还是可以是双向的？我会说它只能是单向的？
2. 我假设 OHS 不能代替 AL ，而是位于应用程序服务/AL之上？
3.
a)是否应将 OHS 也用于同一应用程序的BC之间的通信，还是应仅将 用于与外部BC的通信？无论答案是什么，请详细说明您的推理？
b)假设BC之间相互通信是同一应用程序的一部分，并且假设我们不使用 OHS -这些BC之间是否应该直接相互通信(即BC将调用 ACL ，这反过来将使直接致电BC)还是通过 AL (即BC会调用 ACL ，后者会调用 AL ，然后直接致电BC)？
我认为这些BC应该直接通信，而不应该通过 AL 进行通信，因为它可能会膨胀 AL的接口(interface)，并且还可能向外部系统公开内部功能？
4.
埃里克·埃文(Eric Evan)的DDD书，第16页。 375:
a)我假设我们的 OHS应该仅将我们的应用程序的域模型用作其自身模型的基础？换句话说， OHS 不应该使用应用程序的域模型，而应该基于它自己的模型？
b)由于我们的 OHS具有它自己的模型(通常基于Core Domain，无论可能是什么)，我假设我们还应该在 OHS 和我们的其余应用程序之间定义一个翻译/反腐败层？
c)是否根据应用程序的域模型定义了应用程序服务的参数和返回值？
5.
BC是否总是使用基础结构服务来调用另一个BC(当然，如果BC使用 ACL ，那么BC会调用 ACL ，后者又将调用Infrastructure层，然后再调用另一个BC)，无论是否其他BC是外部的还是同一应用程序的一部分？
谢谢
EULERFX:
1.
a)“或解释从所述服务收到的消息”仅表示我们的 ACL 可以接收来自被叫外部BC的答复(即返回值)，或者您还表示相同的 ACL 当外部BC调用我们的 BC时，发送消息(代表我们的 BC)也可以解释消息？
b)如果以前是，那么从某种意义上说 OHS 也不是双向的，因为外部系统调用的 OHS 服务也可以将答复(即返回值)发送回这些外部系统？如果 4b)中的后面是，则您说 OHS 本身也充当翻译器，这表明当外部系统调用我们的BC时，也不会使用我们的 BC用于调用外部系统的ACL，这意味着 ACL 不能是双向的？
3.
相互通信(如果BC使用 ACL ，则BC将直接称为 ACL ojit，将 ACL称为其他BC)，而不通过 AL 吗？为什么？
如果不使用OHS，请致电另一个BC的应用程序服务。
a)因此，您是说BC应该调用 ACL ，它将调用 AL ，然后可以直接调用另一个BC？
b)同一应用程序内的BC是否共享相同的 AL ？
c)如果内部BC确实共享相同的 AL ，这并不意味着我们可能被迫定义某些应用程序服务，这些服务的唯一目的是使内部BC能够相互通信(因此，外部客户端无意调用这些特定的应用程序服务)。这样，这些应用程序服务是否不会向外部客户端公开内部功能？
说明:我知道，外部客户端只有在引用包含我们应用程序服务的dll的情况下，才能直接调用我们的应用程序服务，但是如果某些客户端确实引用了此类dll的话，则有可能他们可能会调用预期的应用程序服务仅由内部BC互相调用使用？
4.
b)
实际上，OHS将是该翻译层。它将委托(delegate)
应用程序服务的所有行为，在适应过程中
用于实现OHS的特定技术。
根据Evans的说法， OHS 应该仅将基础域模型用作其自身模型的基础，这意味着这两个模型应该是单独的“实例”。
领域模型应该完全遗忘除其建模的领域以外的任何内容。不相同的规则也适用于 OHS 模型吗？换句话说， OHS 模型不应该不了解其他层和域，因此不应该将消息从其自身的模型转换为由基础 AL 封装的域模型吗？
C)
根据DTO定义接口(interface)
假设应用程序服务的接口(interface)是根据DTO定义的: OHS 是根据 OHS 模型定义的，而应用程序服务则封装了域模型，但是什么模型定义了这些DTO？换句话说，这些DTO是 OHS 模型的一部分，还是 AL 封装的域模型的一部分，还是...？
5.
可以说，无论被叫BC是内部的还是内部的
在外部，您仍然在某种程度上采用ACL。
a)仅当存在外部模型泄漏到我们模型中的危险时才不应该使用 ACL 吗？
b)由于内部BC(同一应用程序中的BC)应通过 AL彼此对话，我假设您将通过基础结构层将这些BC称为 AL ，因为域层不应该对上层有任何依赖性(即 AL )？
c)因此，您不同意@ mrhobo ，它指出内部BC应该彼此直接
EULERFX，第二次更新:
1。
b)
由OHS执行的翻译与ACL类似，是
本质上有所不同，因为它具有技术特征。
因此，Evans的意思是(第368页)“ACL可以是双向的” ，因为如果按照您的建议实现了通信，则 ACL 永远不可能是双向的(而所使用的 ACL1 可以被使用BC1 a从 BC2 回复，即使 BC2 调用 BC1 ，即使 BC1 和 BCt会内部使用BC2的笔记，也会永远不使用 BC2 ACL ，我只是指出Evans谈论双向 ACL ，换句话说，他的意思是当 BC2 调用 BC1 时， ACL1会收到此调用吗？
3.
如上所述，BC应该共享应用程序服务，即使它们是内部的。
那没有多大意义。
a)我认为这是拼写错误，您的意思是应该而不是应该？
b)内部BC还不共享 OHS 吗？
c)如果内部BC通过 OHS 相互通信，我们将不会遇到与这些BC通过 AL 进行通信时遇到的相同问题(即，我们可能被迫定义一些 OHS 服务，其唯一目的是启用内部BC相互通信，因此 OHC 这些服务可能向外部客户端公开内部功能)？
5.
一种)
是的，但是如果您调用某些人，情况总是如此
外部BC。如果BC是本地拥有的，那么您可以拥有一些
关于模型(共享内核)的共同协议(protocol)，但仍然很常见
更容易将它们解耦。
我认为，即使脱钩，如果两个BC之间的公共(public)接口(interface)足够简单(至少我是这样理解Evans的)，我们仍然可以拥有一个简单的转换层(而不是完整的 ACL )？
MRHOBO
3。
b)
AL旨在将域与其用户和使用方式分开
用法。居住在同一应用程序中的不列颠哥伦比亚省不应该
通过这些层进行通信，但应成为其中的一部分
同一域层。
因此，您不同意@ eulerfx 关于内部BC通过互相调用AL 的观点吗？为什么？
2)
它可以位于AL的顶部，但也可以直接位于AL的顶部
公元前。 AL和OHS非常相似。如果BC的所有用法
在我看来，取决于OHS，几乎没有必要创建一个
在AL之间。
您能澄清一下在什么情况下BC的所有用法都将仅取决于 OHS ，以及何时还取决于 AL AL 吗？
4，
b)
您将需要适配器来在域模型和域模型之间转换
互动模型，是的。但是，ACL旨在整合两个
BC的使用方式使得使用ACL的BC不了解
另一个卑诗省的存在。这对于使用
OHS，但不应放在服务器上的OHS和BC之间
边。
换句话说， OHS 和 AL 之间的翻译器不应该是 ACL ，而应该是“常规”翻译器？
最佳答案
1.a)OHS是单向的还是双向的？我会说它只能是单向的？
确实，需要通过其自己的接口(interface)访问其他服务的服务根本不是一项服务。
1.b)同样，AL是单向的还是双向的？
类似地，需要访问使用该层的层的层根本不是一个层。与所有分层体系结构一样:依赖关系仅是一种方式。
2)我认为OHS不会取代AL，而是位于应用程序服务/AL之上？
它可以位于AL的顶部，但也可以直接位于BC的顶部。 AL和OHS非常相似。如果我认为BC的所有使用都取决于OHS，则几乎不需要在AL之间创建一个in。
3.a)OHS是否还应用于同一应用程序的BC之间的通信，还是仅用于与外部BC的通信？无论答案是什么，请详细说明您的推理？
这完全取决于您的用例，需求和环境。通常，OHS的构建和维护成本并不便宜，并且出于成本和简便性的考虑，通常避免使用OHS。但是，可能有充分的理由在同一个应用程序中拥有OHS，例如，出于可用性或性能方面的原因而需要分发应用程序时，或者当多个团队在应用程序的不同可互换部分的不同位置上进行工作时。
3.b)假设BC之间相互通信是同一应用程序的一部分，并且假设我们不使用OHS，则这些BC之间是否应直接相互通信(即BC将调用ACL，而ACL又将直接调用ACL) BC)还是通过AL(即BC会调用ACL，后者将调用AL，然后直接调用BC)？
BC可以直接或间接地以许多不同的方式进行通信。这些是DDD概述的模式:客户/供应商，共享内核，反腐败层等。需要明确的是:但是，应用层不是其中之一。 AL旨在将域与其用户和使用方式分开。生活在同一应用程序中的不同BC不应通过此类层进行通信，而应成为同一域层的一部分。应当使用哪种模式来集成BC。 ACL在处理遗留代码时会派上用场，但是，如果您像大多数应用程序开发一样，同时控制两个BC，则肯定不是最佳的解决方案。
4.a)我假设我们的OHS应该仅将应用程序的域模型用作其自身模型的基础？换句话说，OHS不应使用应用程序的域模型，而应仅基于它自己的模型？
是的。如果您不将域模型与交互模型分开，那么您就不再是域建模。交互模型通常涉及与领域无关的概念。
4.b)由于我们的OHS具有它自己的模型(通常基于Core Domain，无论可能是什么模型)，我假设我们还应该在OHS与应用程序其余部分之间定义一个翻译/反腐败层？
您将需要适配器在域模型和交互模型之间转换，是的。
但是，ACL的目的是将两个BC集成在一起，以使使用ACL的BC不会意识到另一个BC的存在。对于使用OHS的客户端，这很方便，但不应在服务器端的OHS和BC之间使用。
4.c)是否根据应用程序的域模型定义了应用程序服务的参数和返回值？
他们可以是。这样做通常是为了节省时间，但它不应使您的域模型成为应用程序感知的。
5)BC是否始终使用基础结构服务来调用另一个BC(当然，如果BC使用ACL，则BC会调用ACL，ACL进而会调用基础结构层，然后再调用另一个BC)，而不管该另一个BC是否外部还是同一应用程序的一部分？
BC之间的通信并不总是必须跨层。正如我之前说过的，几个BC可以生活在同一个域层中，并且可以DDD概述的几种方式进行集成。当BC是同一非分布式应用程序的一部分时，这适用。分发BC时，这些BC将需要使用基础结构层来与其外部对等方进行交互。
更新
因此，您不同意@eulerfx关于内部BC通过AL相互调用的观点吗？为什么？
是的，看来我愿意。
应用程序层的职责是从其他类型的逻辑(例如表示形式和基础结构逻辑)中抽象出应用程序逻辑，并在应用程序内创建一个单一的真理点。应用程序层模式不是DDD定义的，也不是BC集成模式，例如共享内核，一致性，客户/供应商和反腐败层。
一个应用程序具有一个应用程序层。当您将应用程序层视为BC周围的外观时，eulerfx的建议是正确的，这通常是正确的，但这根本不是应用程序层的定义。如果愿意，请查找它。
您能澄清一下在什么情况下，BC的所有使用都仅取决于OHS，什么时候还取决于AL？
AL和OHS非常相似。 AL打算在应用程序中使用，而OHS则用于外部通信。两者都是门面。当您的应用程序没有表示层，只有OHS时，创建一个介于两者之间的应用程序层是没有意义的。当应用程序具有表示层但还通过OHS公开其BC时，表示层将使用AL，而外部系统将使用OHS，而OHS则将使用AL。
如果存在OHS，则应依赖于AL，因为AL应该是一个真实的点。
换句话说，OHS和AL之间的转换器不应该是ACL，而应该是“常规”转换器？
确切地。
ACL是BC的一部分，但实际上是从另一个BC获取其信息的。这将所有凌乱的集成部分抽象出来，并使BC能够以适合域的方式进行编码。 ACL可以防止BC因这些集成问题而损坏。
这是一个实际示例:https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used
关于domain-driven-design - 打开主机服务VS应用程序层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16778125/