问题描述
OHS ...打开主机服务
AL ...应用层
ACL ...反腐败层
BC ...受限上下文
OHS ... Open Host Service
AL ... Application Layer
ACL ... AntiCorruption Layer
BC ... Bounded Context
1。
在这里，我会在我们的 OHS的公共界面上使用单向 / em>仅可由外部 BC呼叫我们的系统，但不能由我们的BC呼叫 >外部系统
Here I'll use the term unidirectional when our OHS's public interface can only be used by external BCs to call our system, but it can't be used by our BCs to call external systems
类似地，当我们的 时，我将使用术语双向 Oem的公共接口可供外部 BC呼叫我们的系统，但也可以由我们的 BC呼叫外部系统
Similarly, I'll use the term bidirectional when our OHS's public interface can be used by external BCs to call our system, but it can also be used by our BCs to call external systems
a）是 OHS 单向还是 >双向？我会说它只能是单向？
a) Is OHS unidirectional or can it also be bidirectional? I'd say it can only be unidirectional?
b）同样，是 AL 单向还是双向？我会说它只能是单向？
b) Similarly, is AL unidirectional or can it also be bidirectional? I'd say it can only be unidirectional?
2。。我假设 OHS >不会取代 AL ，而是位于应用程序服务/ AL 之上？
2. I assume OHS doesn't replace AL, but instead sits on top of Application services/AL?
3。
a） OHS 是否也应用于同一应用程序的BC之间的通信，或者仅可用于与外部 BC通信？不管答案是什么，请详细说明原因。
a) Should OHS also be used for communication between BCs that are part of the same application or should it only be used for communication with external BCs? Whatever the answer, please elaborate your reasoning?
b）假设BC之间相互通信是同一应用程序的一部分，并假设我们不使用 OHS -如果这些BC之间直接进行 通讯（即BC会呼叫 ACL ，从而直接呼叫BC）或通过 AL （即，BC将呼叫 ACL ，后者将呼叫 AL ，然后直接呼叫BC）？
b) 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 )?
我认为这些BC应该直接通信 而不是通过 AL 进行通信，因为这可能会使 > AL的界面，还可能向外部系统公开内部功能？
I'd argue that these BCs should communicate directly and not via AL, since it may bloat AL's interface and may also expose inner functionality to external systems?
4
Eric Evan的DDD书，第pg。 375：
Eric Evan's DDD book, pg. 375:
a）我认为我们的 OHS应该仅将我们的 应用程序的域模型用作自身模型的基础？换句话说， OHS 不应该使用应用程序的域模型，而是应该仅基于它的自己的模型？
a) I assume our OHS should use our application's domain model only as the basis for its own model? In other words, OHS shouldn't use application's domain model, but should instead just base its very own model on it?
b）由于我们的，OHS具有自己的模型（通常基于核心域 ，无论是什么），我假设我们还应该在 OHS 和我们的其余应用程序之间定义一个翻译/反腐败层？
b) 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?
c）是根据应用程序的 定义的应用程序服务的自变量和返回值 >域模型？
c) Are arguments and return values of Application services defined in terms of application's domain model?
5。
BC是否总是使用基础架构服务呼叫另一个BC（当然，如果BC使用的是 ACL ，那么BC会呼叫 ACL ，而BCL会依次呼叫 Infrastructure layer ，然后将其称为另一个BC），无论另一个BC是外部还是山姆的一部分电子申请？
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?
谢谢
EULERFX：
1。
a） 或解释从所述服务收到的消息仅表示我们的 ACL 可以收到答复（即返回值）来自称为外部 BC的还是您的意思是相同 ACL 当外部 BC呼叫我们的 BC时，发送消息（代表我们的 BC）的邮件还可以解释这些消息？
a) By "or interpreting a message received from said service" you mean only that our ACL can receive a reply ( ie. return value ) from the called external BC or do you also mean that the same ACL which sends messages ( on behalf of our BCs ) can also interpret the messages when external BCs call our BCs?
b）如果前者，那么 OHS 也不是双向，因为 OHS 服务被调用者d由 external 系统也可以发送 reply （即返回值）返回到这些外部系统？如果后期，在 4b）中，您说 OHS 本身也起着 translator 的作用，则表明 我们的 BC用于呼叫外部系统的> ACL 也不会在 external 系统呼叫我们的BC时使用。暗示 ACL 不能是双向？
b) If the former, then isn't in that sense OHS also bidirectional since OHS services called by external systems can also send reply ( ie. return value ) back to these external systems? 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?
3。
如果不使用OHS，则调用应用程序
If not using OHS, call the application service of the other BC.
a）因此，是说BC应该呼叫 ACL ，后者将呼叫 AL ，然后直接呼叫另一个BC？
a) So you're saying that BC should call ACL, which would call AL, which then would make a direct call to the other BC?
b）相同应用程序 share 中的BC是否与 AL 相同？
b) Do BCs within the same application share the same AL?
c）如果内部 BC确实共享相同的 AL ，这并不意味着我们可能会被迫定义某些应用程序服务，其唯一目的是使内部 BC能够相互通信（因此，外部客户端并不意味着将它们称为特定的应用服务）。因此，这些应用程序服务是否不会向外部客户端公开内部功能？
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 clients are not meant to call these particular Application services ). As such, don't these Application services expose inner functionality to external clients?
说明：我知道外部客户只能直接致电我们的应用服务如果他们对包含我们的应用服务的 dll 的引用，但是如果某些 clients 确实对此类 dll ，那么它们可能会调用应用程序服务，该服务仅由内部彼此调用的BC使用？
Clarification: I know that external clients can only directly call our Application services if they have a reference to dll containing our Application services, but if some clients do have a reference to such dll, then there's a possibility they may call Application services intended to be used only by internal BCs calling each other?
4。
b）
实际上，OHS将是该翻译层。在适应于用于实施OHS的
特定技术的过程中，它将把
的所有行为委派给应用程序服务。
In effect, the OHS will be that translation layer. It will delegate all behavior to application service, in the process adapting to the specific technology used to implement OHS.
根据Evans的说法， OHS 应该仅使用基础域模型作为其自身模型的基础，这意味着两个模型应该是
According to Evans, OHS should use the underlying domain model only as the basis for its own model, meaning the two models should be separate "instances".
域模型应该完全忽略除其建模的 domain 以外的任何内容。相同的规则也不适用于 OHS 模型吗？换句话说， OHS 模型不应不了解其他层和域，因此不应为翻译其自身模型中的消息而烦恼放入由基础 AL 封装的域模型中？
Domain models should be completely oblivious to anything except the domain they model. Don't same rules also apply to OHS model? In other words, shouldn't OHS model be unaware of other layers and domains and as such it shouldn't be bothered with translating messages from its own model into the domain model encapsulated by the underlying AL?
c）
根据DTO定义接口
假设应用服务的接口是根据DTO定义的： OHS 是根据 OHS 模型和 Application定义的服务封装了域模型，但是什么模型定义了这些DTO？换句话说，这些DTO是 OHS 模型的一部分，还是 AL 封装的域模型的一部分。 。？
Assuming the interfaces of Application Services are defined in terms of DTOs: OHS is defined in terms of OHS model and the Application Services encapsulate the domain model, but what model defines these DTOs? In other words, are these DTOs part of OHS model, part of domain model encapsulated by AL or... ?
5。
可以说，无论被叫BC是内部的还是外部的
，您都仍然可以采用ACL进行某种程度的控制。
It can be said that regardless of whether the called BC is internal or external, you still employ an ACL to one degree or another.
a）仅当存在外部模型泄漏到我们的模型的危险时，才不应该应用 ACL 吗？
a) Shouldn't ACL be applied only when there's a danger of the outside model leaking into our model?
b）由于内部 BC（同一应用程序中的BC）应通过 AL 相互对话，假设您会通过基础结构层将这些BC呼叫 AL ，因为域层不应与上层有任何依赖（即 AL ）？
b) Since internal BCs ( BCs within the same application ) should talk to each other via AL, I assume you'd have these BCs call AL via Infrastructure layer, since Domain layer shouldn't have any dependencies on upper layers ( ie. AL )?
c）所以您不同意@ mrhobo 内部 BC应该相互之间直接通信（如果BC使用 ACL ，则BC将直接呼叫 ACL ，又将其称为另一个BC而不是通过 AL ？为什么？
c) So you disagree with @mrhobo, which states that internal BCs should communicate with each other directly ( if BC is using ACL, then BC would directly call ACL, which in turn would call the other BC ) and not via AL? Why?
EULERFX，第二次更新：
1。
b）
OHS进行的翻译与$ A $类似，但与ACL相似因为它具有技术性。
The translation performed by the OHS, while similar to an ACL is different in nature because it is of a technical character.
Evans的意思是（第368页） ACL可以是双向的，因为如果按照您的建议实施了通讯，则 ACL 永远不会是双向（（使用 ACL1 BC1 可以从 BC2 收到回复， ACL1 永远不会在 BC2 呼叫 BC1 时使用，即使 BC1 和 BC2 都是内部 –请注意，我知道 BC2 将使用其自己的 ACL ，我只是指出 Evans 谈论了双向 ACL 。换句话说，他的意思是当 BC2 呼叫 BC1 时，此呼叫会被 ACL1 接听吗？）？
So what did Evans mean by ( pg. 368 ) "ACL can be bidirectional" , since if communication is implemented as you suggest, then ACL can never be bidirectional ( while ACL1 used by BC1 can receive a reply from BC2, ACL1 will never be used when BC2 calls BC1, even if both BC1 and BC2 are internal – note that I'm aware that BC2 will use its own ACL, I'm just pointing out that Evans talks about bidirectional ACLs. In other words, he's implying that when BC2 calls BC1, this call would be received by ACL1 )?
3。
如上所述， BC应该共享应用程序服务，即使它们是内部的。
没什么意义。
As above, BCs should share application services even if they internal. That doesn't make much sense.
a）我以为是错字，你的意思是 t 而不是应该？
a) I assume it's a typo and you meant shouldn't instead of should?
b）内部 BC也不会共享 OHS ？
b) Internal BC also don't share OHS?
c）如果内部 BC通过 OHS 相互通信，我们是否会遇到与这些BC通过 AL 进行通信（即，我们可能被迫定义某些 OHS 服务，其唯一目的是启用内部 BC彼此通信，因此，这些 OHC 服务可能向外部客户端公开 inner 功能）？
c) If internal BCs communicated with each other via OHS, wouldn't we face same problems as when these BCs communicate via AL ( ie. we may be forced to define some OHS services whose only purpose is to enable internal BCs to communicate with each other, and as such these OHC services may expose inner functionality to external clients )?
5。
a）
是的，但是如果您要呼叫某些
外部BC，则情况总是如此。如果BC是本地拥有的，则可以在模型（共享内核）上有
的相互协议，但是
往往更容易解耦。
Yes, but that will always be the case if you're calling some external BC. If the BCs are locally owned then you can have some mutual agreement on model (shared kernel), but it is still often easier to decoupled them.
我认为即使去耦，我们仍然可以拥有一个简单的翻译层（而不是完整的 ACL ），如果两个BC之间的公共接口是简单（至少我是这样理解Evans的）？
I thought even when decoupled, we can still have a simple translation layer ( instead of full blown ACL ) if the public interface between two BCs is simple enough ( at least that's how I understood Evans )?
MRHOBO
3。
b）
AL的作用是将域与用户以及
的使用方式分开。居住在同一应用程序中的不同BC不应
通过此类层进行通信，而应成为
同一域层的一部分。
The AL is meant to separate the domain from it's users and ways of usage. Different BC's living within the same application should not communicate through such layers, but should instead be part of the same domain layer.
所以您不同意@ eulerfx 关于内部 BC通过 AL 相互呼叫的信息吗？为什么？
So you disagree with @eulerfx about internal BCs calling each other through AL? Why?
2）
它可以位于顶部AL，但也可以直接位于BC的
上方。 AL和OHS非常相似。如果我认为BC
的所有用法都取决于OHS，那么在AL之间几乎不需要创建
。
It could sit on top of an AL, but could also sit directly on top of the BC. An AL and a OHS are very similar. If all usage of the BC depends on the OHS, in my opinion, there is little need to create an in between AL.
您能说明在什么情况下所有的BC用法仅取决于 OHS ，何时还取决于 AL ？
Could you clarify in what situations all usage of BC would depend only on OHS and when would it also depend on AL?
4。
b）
您将需要适配器在域模型和
互动模型，是的。但是，ACL的目的是将两个
BC集成在一起，以使使用ACL的BC不知道另一个BC的
的存在。对于使用
OHS的客户端来说，这很方便，但不应在服务器
端的OHS和BC之间使用。
You will need adaptors to translate between the domain model and the interaction model, yes. The ACL, however, is meant to integrate two BC's in such a way that the BC that uses the ACL is unaware of the existence of another BC. This comes in handy for a client using an OHS, but should not go in between the OHS and the BC on the server side.
换句话说， OHS 和 AL 之间的 translator 不应为 ACL ，但只是一个常规 翻译器？
In other words, the translator between OHS and AL shouldn't be ACL, but instead just a "regular" translator?
推荐答案
1.a） OHS是单向的还是双向的？我会说它只能是单向的？
确实，需要通过自己的界面访问其他服务的服务根本不是一项服务。
Exactly, a service that needs to access other services through it's own interface is not a service at all.
1.b）同样，AL是单向的还是双向的？
类似地，需要访问使用该层的层的层根本不是一个层。就像所有分层体系结构一样：依赖关系仅是一种方式。
Similarly, a layer that needs to access layers that use that layer is not a layer at all. As with all layered architecture: dependencies go one way only.
2）我认为OHS不会取代AL，而是位于应用程序服务/ AL？
它可以位于AL的顶部，但也可以直接位于BC的顶部。 AL和OHS非常相似。如果我认为BC的所有使用都取决于OHS，则几乎不需要在AL之间创建一个in。
It could sit on top of an AL, but could also sit directly on top of the BC. An AL and a OHS are very similar. If all usage of the BC depends on the OHS, in my opinion, there is little need to create an in between AL.
3.a）OHS是否也应用于同一应用程序的BC之间的通信，还是仅用于与外部BC的通信？不管答案是什么，请详细说明原因吗？
这一切都取决于您的用例，需求和环境。通常，OHS的构建和维护成本并不便宜，并且出于成本和简便性的考虑，通常避免使用OHS。但是，可能有充分的理由在同一个应用程序中拥有OHS，例如，出于可用性或性能原因而需要分发应用程序时，或当多个团队在应用程序的不同可互换部分的不同位置上工作时。
It all depends on your use-cases, requirements and environment. An OHS is usually not cheap to build and maintain and are usually avoided for cost and simplicity's sake. There might be good reasons to have an OHS within the same application though, for example when the application needs to be distributed for availability or performance reasons or when several teams are working on different locations on different interchangeable parts of the application.
3.b）假定彼此通信的BC是同一应用程序的一部分，并假设我们不使用OHS-这些BC是否应彼此通信是直接（例如，BC呼叫ACL，这将直接呼叫BC）还是通过AL（例如，BC呼叫ACL，后者将呼叫AL，然后直接呼叫BC）？
BC可以直接或间接地以多种不同方式进行通信。这些是DDD概述的模式：客户/供应商，共享内核，反腐败层等。要明确：但是，应用层不是其中之一。 AL旨在将域与用户和使用方式分开。居住在同一应用程序中的不同BC不应通过这些层进行通信，而应属于同一域层。应当使用哪种模式来整合BC。 ACL在处理遗留代码时会派上用场，但是，如果您像大多数应用程序开发一样，同时控制两个BC，则肯定不是最佳的解决方案。
BC's can communicate in many different ways, directly and indirectly. These are the patterns outlined by DDD: Customer/Supplier, Shared Kernel, anti-corruption layer, etc. To be clear: the Application Layer, however, is not one of them. The AL is meant to separate the domain from it's users and ways of usage. Different BC's living within the same application should not communicate through such layers, but should instead be part of the same domain layer. Which pattern should be used to integrate BC's again depends. An ACL comes in handy when working with legacy code, but is certainly not the most optimal solution if you are in control of both BC's as is the case with most application development.
4.a）我认为我们的OHS应该仅将应用程序的域模型用作其自身模型的基础？换句话说，OHS不应使用应用程序的域模型，而应仅基于应用程序的域模型？
是。如果您没有将域模型与交互模型分开，那么您就不再是域建模。交互模型通常涉及与领域无关的概念。
Yes. If you don't separate your domain model from your interaction model you are not domain modeling anymore. Interaction models usually involve concepts that have nothing to do with the domain.
4.b）由于我们的OHS具有其自己的模型（通常基于Core Domain，无论可能是什么），我认为我们应该还定义了位于OHS和应用程序其余部分之间的转换/反腐败层吗？
您将需要适配器来在域模型和交互模型之间转换，是的。
You will need adaptors to translate between the domain model and the interaction model, yes.
但是，ACL的目的是将两个BC集成在一起，这样使用ACL的BC不会意识到另一个BC的存在。对于使用OHS的客户端来说，这很方便，但不应在服务器端的OHS和BC之间使用。
The ACL, however, is meant to integrate two BC's in such a way that the BC that uses the ACL is unaware of the existence of another BC. This comes in handy for a client using an OHS, but should not go in between the OHS and the BC on the server side.
4.c）是根据应用程序的域模型定义的应用程序服务的参数和返回值？
它们可以是。这样做通常是为了节省时间，但是它不会使您的域模型变得对应用程序敏感。
They can be yes. This is done quite often to save time, but it should not cause your domain model to become application aware.
5）BC是否总是使用基础设施服务来呼叫另一个BC（当然，如果BC使用ACL，那么BC会调用ACL，ABC又会调用基础结构层，然后再调用另一个BC），而不管另一个BC是外部的还是同一应用程序的一部分？
不列颠哥伦比亚省之间的通信不必总是跨越层级。正如我之前说过的，几个BC可以生活在同一域层中，并且可以DDD概述的几种方式进行集成。当BC是同一非分布式应用程序的一部分时，这适用。当分发了BC时，这些BC将需要使用基础结构层来与外部对手进行交互。
Communication between BC's do not always have to cross layers. As I've said before, several BC's can live within the same domain layer and can be integrated in several ways outlined by DDD. This applies when the BC's are part of the same non-distributed application. When BC's are distributed, then these BC's will need to use an infrastructure layer to interact with their external counterpart.
更新
所以您不同意@eulerfx关于内部BC通过AL相互呼叫的信息？为什么？
是的，看来是的。
应用程序层的职责是从其他类型的逻辑（例如表示形式和基础结构逻辑）中抽象出应用程序逻辑，并在应用程序内创建一个真实的点。应用程序层模式不是DDD定义的，也不是BC集成模式，例如共享内核，一致性，客户/供应商和反腐败层。
一个应用程序具有一个应用程序层。当您将应用程序层视为BC周围的外观时，eulerfx的建议是正确的，这通常是正确的，但这根本不是应用程序层的定义。
An application layers' responsibility is to abstract application logic from other types of logic (like presentation and infrastructure logic) and to create a single point of truth within an application. The application layer pattern was not defined by DDD and is not a BC integration pattern, like shared kernel, conformist, customer/supplier and anti-corruption layer. One application has one application layer. It is not wrong what eulerfx suggests when you think of the application layer as a facade around the BC, which it often is, but that is simply not the definition of an application layer. Look it up if you will.
能否请您说明在什么情况下BC的所有使用仅取决于OHS，何时还取决于AL？ / em>
Could you clarify in what situations all usage of BC would depend only on OHS and when would it also depend on AL?
AL和OHS非常相似。 AL打算在应用程序中使用，而OHS则用于外部通信。两者都是门面。当您的应用程序没有表示层，只有OHS时，创建一个介于两者之间的应用程序层是没有意义的。当应用程序具有表示层但还通过OHS公开其BC时，表示层将使用AL，而外部系统将使用OHS，后者将使用AL。
An AL and an OHS are quite similar. An AL is meant to be used within an application and an OHS for external communications. Both are facades. When your application has no presentation layer, only an OHS, there is no point in creating an application layer to go in between. When an application has a presentation layer but also exposes it's BC via an OHS, the presentation layer would use the AL and external systems would use the OHS, which would in turn would use the AL.
OHS应该依赖于AL（如果存在），因为AL应该是一个真实的点。
An OHS should depend on an AL if present, because an AL should be a single point of truth.
换句话说，OHS和AL之间的转换器不应该是ACL，而应该是常规转换器？
是的。
ACL是BC的一部分，但实际上是从另一个BC获取其信息的。这将所有凌乱的集成部分抽象出来，并使BC能够以适合域的方式进行编码。 ACL可以防止BC因这些集成问题而损坏。
An ACL is part of a BC, but in fact gets its information from another BC. This abstracts all the messy integration parts away and makes it possible for a BC to be coded in a way that fits the domain . An ACL prevents the BC from getting corrupted with these integration issues.
这是一个实际示例：
这篇关于打开主机服务VS应用程序层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！