Edv*_*usj 12 domain-driven-design
OHS ...开放主机服务
AL ...应用层
ACL ... AntiCorruption Layer
BC ...有界上下文
1.
当我们的OHS的公共接口只能被外部 BC用来调用我们的系统时,我将使用单向一词,但我们的 BC 不能用它来调用外部系统
同样,当我们的OHS的公共接口可以被外部 BC用来呼叫我们的系统时,我将使用术语双向,但我们的 BC 也可以使用它来调用外部系统
a)OHS 是单向的还是双向的？我会说它只能是单向的吗？
b)同样,AL 是单向的还是双向的？我会说它只能是单向的吗？
2.我认为OHS不会取代AL,而是取代应用服务/ AL？
3.
a)OHS是否也应用于属于同一应用的BC之间的通信,还是仅用于与外部 BC的通信？无论答案是什么,请详细说明你的推理？
b)假设BC相互通信是同一个应用程序的一部分,并假设我们不使用OHS - 这些BC是否应该直接相互通信(即BC会调用ACL,而ACL会直接调用BC)或通过AL(即BC将调用ACL,这将调用AL,然后将直接调用BC)？
我认为这些BC应该直接通信而不是通过AL进行通信,因为它可能会使AL的接口膨胀并且还可能将内部功能暴露给外部系统？
4.
Eric Evan的DDD书,pg.375:
Open Host Service使用标准化协议进行多方集成.它采用域的模型进行系统之间的交换,即使该模型可能不被这些系统内部使用.
a)我认为我们的 OHS应该仅使用我们的 应用程序的域模型作为其自己模型的基础？换句话说,OHS不应该使用应用程序的域模型,而应该只基于它自己的模型？
b)由于我们的 OHS拥有它自己的模型(通常基于核心域,无论可能是什么),我认为我们还应该定义一个位于OHS和我们应用程序其余部分之间的翻译/反腐败层？
c)应用程序服务的参数和返回值是根据应用程序的域模型定义的吗？
5.
BC是否总是使用基础设施服务来呼叫另一个BC(当然,如果BC使用ACL,那么BC会调用ACL,而ACL又会调用基础设施层,然后调用另一个BC),无论其他BC是外部的还是同一个应用程序的一部分？
谢谢
EULERFX:
1.
1b)ACL是双向的,因为数据以任一方向流动 - 无论是向外部服务发送消息还是解释从所述服务接收的消息.
a)通过" 或解释从所述服务接收的消息 ",你的意思是我们的 ACL 只能从被叫外部 BC 接收回复(即返回值),或者你是否也意味着发送消息的同一ACL(代表当外部 BC调用我们的 BC 时,我们的 BCs)还可以解释这些消息吗？
b)如果前者,那么在那个意义上OHS也不是双向的,因为外部系统调用的OHS 服务也可以将回复(即返回值)发送回这些外部系统？如果后者在4B)你说OHS本身也充当翻译,这表明ACL使用我们的 BC调用外部系统时不会也可用于外部系统调用我们的BC,这将意味着ACL不能是双向的？
3.
3b)假设BC相互通信是同一个应用程序的一部分,并假设我们不使用OHS - 这些BC是否应该直接相互通信(即BC会调用ACL,而ACL会直接调用BC)或通过AL(即BC将调用ACL,这将调用AL,然后将直接调用BC)？
如果不使用OHS,请调用其他BC的应用程序服务.
a)所以你说BC应该调用ACL,它会调用AL,然后它会直接调用另一个BC？
b)同一个应用程序中的BC是否共享同一个AL？
c)如果内部 BC确实共享相同的AL,这并不意味着我们可能被迫定义一些 应用服务,其唯一目的是使内部 BC能够相互通信(因此外部客户端并不打算称这些特定的应用服务).因此,这些应用程序服务不会向内部客户端公开内部功能吗？
澄清:我知道,外部客户端只能直接拨打我们的应用程序服务,如果他们有一个参考dll的包含我们的应用程序服务,但如果有些客户确实有这样的引用的DLL,然后有一个可能性,他们可以调用应用程序服务旨在仅由内部 BC相互使用？
4.
b)
我假设我们还应该在OHS和我们的其他应用程序之间定义一个翻译/反腐败层？
实际上,OHS将是该翻译层.它将所有行为委托给应用程序服务,在此过程中适应用于实现OHS的特定技术.
根据Evans的说法,OHS应该仅使用底层域模型作为其自身模型的基础,这意味着两个模型应该是独立的"实例".
域模型应该完全忽略除了他们建模的域之外的任何东西.不同的规则也适用于OHS 模型吗？换句话说,OHS 模型不应该不知道其他层和域,因此不应该将消息从其自己的模型转换为由底层AL封装的域模型吗？
C)
应用程序服务的参数和返回值是根据应用程序的域模型定义的吗？
根据DTO定义接口
假设应用服务的接口是根据DTO 定义的:OHS是根据OHS 模型定义的,而应用服务封装了域模型,但是什么模型定义了这些DTO？换句话说,这些DTO是OHS 模型的一部分,是由AL封装的域模型的一部分还是......？
5.
BC是否总是使用基础设施服务来呼叫另一个BC(当然,如果BC使用ACL,那么BC会调用ACL,而ACL又会调用基础设施层,然后调用另一个BC),无论其他BC是外部的还是同一个应用程序的一部分？
可以说无论被叫BC是内部还是外部,你仍然可以在某种程度上使用ACL.
a)只有当外部模型有泄漏到我们模型中的危险时,才应该应用ACL吗？
b)由于内部 BC(同一应用程序中的BC)应该通过AL相互通信,我假设你有这些BC 通过Infrastructure层调用AL,因为Domain层不应该对上层有任何依赖(即AL))？
c)所以你不同意@ mrhobo,它声明内部 BC应该直接相互通信(如果BC使用ACL,那么BC会直接调用ACL,而后者又调用另一个BC)而不是通过AL？为什么？
EULERFX,第二次更新:
1.
b)
如果后者,在4b)你说OHS本身也充当翻译器,这表明我们的BC用于调用外部系统的ACL在外部系统调用我们的BC时也不会被使用,这意味着ACL不能是双向的？
由OHS执行的翻译虽然与ACL类似,但在本质上是不同的,因为它具有技术特征.
那么埃文斯的意思是什么(第368页)"ACL可以是双向的",因为如果按照你的建议实现通信,那么ACL永远不能是双向的(而BC1使用的 ACL1可以从BC2接收回复,ACL1将永远不会当BC2调用BC1时使用,即使BC1和BC2都是内部的 - 注意我知道BC2将使用自己的ACL,我只是指出Evans谈论双向ACL.换句话说,他暗示当BC2呼叫BC1,此呼叫将由ACL1接收？
3.
c)如果内部BC确实共享相同的AL,这并不意味着我们可能被迫定义一些应用服务,其唯一目的是使内部BC能够相互通信(因此外部客户端并不意味着要调用这些特定的应用程序)服务 ).因此,这些应用程序服务不会向内部客户端公开内部功能吗？
如上所述,BC应该共享应用服务,即使它们是内部的.这没有多大意义.
a)我认为这是一个错字,你的意思是不应该而不是应该？
b)内部 BC也不共享OHS？
c)如果内部 BC通过OHS相互通信,我们不会遇到与这些BC通过AL通信时相同的问题(即,我们可能被迫定义一些OHS 服务,其唯一目的是使内部 BC能够与每个BC进行通信其他,因此这些OHC 服务可能会向内部客户公开内部功能)？
5.
一个)
只有当外部模型有泄漏到我们模型中的危险时,才应该应用ACL吗？
是的,但是如果你打电话给一些外部BC,情况总是如此.如果BC是本地拥有的,那么你可以在模型(共享内核)上有一些共同的协议,但是通常更容易将它们分离.
我认为即使在解耦时,如果两个BC之间的公共接口足够简单(至少我理解Evans的方式),我们仍然可以有一个简单的转换层(而不是完整的ACL)？
MRHOBO
3.
b)
假设BC彼此通信是同一个应用程序的一部分,并假设我们不使用OHS - 这些BC是否应该直接相互通信(即BC会调用ACL,而ACL会直接调用BC)或者通过AL(即BC会调用ACL,它会调用AL,然后直接调用BC)？
AL旨在将域与其用户和使用方式分开.生活在同一应用程序中的不同BC不应通过这些层进行通信,而应该是同一域层的一部分.
所以你不同意@ eulerfx关于内部 BC通过AL互相呼叫？为什么？
2)
我认为OHS不会取代AL,而是取代应用服务/ AL？
它可以坐在AL的顶部,但也可以直接坐在BC的顶部.AL和OHS非常相似.如果BC的所有使用取决于OHS,在我看来,几乎不需要在AL之间创建.
你能澄清一下BC在什么情况下只使用OHS,什么时候还要依赖于AL？
4.
b)
由于我们的OHS拥有自己的模型(通常基于Core Domain,无论可能是什么),我认为我们还应该定义一个位于OHS和我们应用程序其余部分之间的翻译/反腐败层？
你需要适配器来在域模型和交互模型之间进行转换,是的.然而,ACL旨在以这样一种方式集成两个BC,即使用ACL的BC不知道另一个BC的存在.这对于使用OHS的客户端来说非常方便,但不应该在服务器端的OHS和BC之间进行.
换句话说,OHS和AL之间的翻译不应该是ACL,而只是一个"常规" 翻译？
1.a)OHS是单向的还是双向的？我会说它只能是单向的吗？
确切地说,需要通过其自己的接口访问其他服务的服务根本不是服务.
1.b)同样,AL是单向的还是双向的？
同样,需要访问使用该层的图层的图层根本不是图层.与所有分层架构一样:依赖关系仅采用一种方式.
2)我认为OHS不会取代AL,而是取代应用服务/ AL？
它可以坐在AL的顶部,但也可以直接坐在BC的顶部.AL和OHS非常相似.如果BC的所有使用取决于OHS,在我看来,几乎不需要在AL之间创建.
3.a)OHS是否也应用于属于同一申请的BC之间的通信,还是仅用于与外部BC的通信？无论答案是什么,请详细说明你的推理？
这完全取决于您的使用案例,要求和环境.OHS通常不便宜构建和维护,并且通常为了成本和简单性而避免使用OHS.可能有充分的理由在同一个应用程序中拥有OHS,例如,当应用程序需要根据可用性或性能原因进行分发时,或者当多个团队在应用程序的不同可互换部分上的不同位置工作时.
3.b)假设BC彼此通信是同一个应用程序的一部分,并假设我们不使用OHS - 这些BC是否应该直接相互通信(即BC会调用ACL,而ACL会直接调用BC)或通过AL(即BC会调用ACL,这会调用AL,然后直接调用BC)？
BC可以直接或间接地以多种不同方式进行通信.这些是DDD概述的模式:客户/供应商,共享内核,反腐败层等.需要明确的是:应用层不是其中之一.AL旨在将域与其用户和使用方式分开.生活在同一应用程序中的不同BC 不应通过这些层进行通信,而应该是同一域层的一部分.应该使用哪种模式来再次集成BC.在使用遗留代码时,ACL会派上用场,但如果您控制两个BC,则肯定不是最佳解决方案,就像大多数应用程序开发一样.
4.a)我认为我们的OHS应该仅使用我们的应用程序的域模型作为其自己的模型的基础？换句话说,OHS不应该使用应用程序的域模型,而应该只基于它自己的模型？
是.如果您不将域模型与交互模型分开,则不再进行域建模.交互模型通常涉及与域无关的概念.
4.b)由于我们的OHS拥有自己的模型(通常基于核心域,无论可能是什么),我认为我们还应该定义一个位于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表示在应用程序中使用,OH表示用于外部通信.两者都是外墙.当您的应用程序没有表示层,只有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