1）
a） ACL Facade 仅提供对其他系统（外部系统）或其他 Bounded Context的那些功能的访问权限也由我们的团队开发）我们的 BC 需要。如果其他系统公开功能（我们的 BC 感兴趣），我们可以将其分类为几个不同的职责，我们是否应该定义一个每个职责的ACL Facade 或者我们应该有单个 ACL Facade 公开所有职责（由外部提供）系统）我们的 BC 需要吗？
b）如果回答 a），我们应该为外部系统提供的每个职责定义一个ACL Facade，我们是否应该定义每个ACL Facade的一个ACL服务？！
2）
a）Evan的书（第366页）：
AntiCorruption Layer的公共界面通常显示为 服务集......在我们的模型中，它甚至可能都没有意义 将外部系统表示为单个组件。这可能是最好的 使用多个服务，每个服务都有一致的责任 我们模型的术语
ACL 本身并不驻留在域层中，但根据上述引用 ACL服务代表 域名概念？如果是这样，我们不能说：
我 - ACL服务是域服务？
II - 域概念已泄露到 ACL ？
b） ACL服务的责任是什么？只需在我们的 BC 和外部系统（即其他 BC ）或 ACL服务之间进行调解即可em>责任与外部系统提供的责任不同，因此 ACL Service 可以使用提供的功能外部系统只执行自己的指定任务？
3）Evan的书（第366页）：AntiCorruption Layer的公共界面通常显示为 服务集......在我们的模型中，它甚至可能都没有意义 将外部系统表示为单个组件。这可能是最好的 使用多个服务，每个服务都有一致的责任 我们模型的术语
作者是说将外部系统表示为具有单一责任可能没有意义，而是系统可能是表示具有多个职责，因此我们将为每个职责定义 ACL Facade + ACL服务（和相应的适配器） ？
4）顺便说一句 - 我假设ACL也可以在同一个应用程序中存在并由同一团队开发的两个 Bounded Contexts 之间定义？
更新
1）
a）我不太了解你的理由：
如果外观由不同的同一项目使用 责任仍然属于同一有限的背景，然后使用 同样的门面。沿着技术凝聚力的好处 外部系统API轴将超过功能的好处 沿责任轴耦合。
予。我假设＆＃34; at ＆＃34;是一个拼写错误，应该替换为＆＃34; 和＆＃34;？
II。通过＆＃34; 不同的责任仍属于同一有界的背景＆＃34;你指的是 Facade 只暴露单一BC 的职责这一事实吗？
III。如果 Facade 公开几个BC 的职责，那么我们应该为每个一个Facade < / strong>这些外部BC ？如果是，为什么它比所有 BC 都有一个Facade更受青睐？仅仅因为 Facade界面会变得一团糟？
IV。通过＆＃34; 如果外观由同一个项目使用＆＃34;你的意思是如果两个BC 都是同一个应用程序的一部分，那么我们应该使用单个Facade 来公开所有责任 ？如果其他 BC 属于不同的应用程序该怎么办？
诉
外部系统API的技术凝聚力的好处 轴将超过沿着功能耦合的好处 责任轴。
为什么技术凝聚力优先于功能耦合？
b）
嗯，我不确定我是否理解这一点。无论如何， ACL服务如何映射到 Facade ？也许每个ACL服务都映射到我们的 Facade 公开的一个责任（即，如果 Facade 公开单一责任，那么我们只有一个ACL服务，如果它公开两个职责，我们有两个ACL服务等）？外观本身实际上是一种服务或一组服务。没必要 定义附加服务。
3）
作者是否说代表外部可能没有意义 系统只有一个责任，而是那个系统 可以表示有几个责任，因此我们 将定义ACL Facade + ACL服务（和相应的适配器） 这些责任各有哪些？
是的，外部系统可能在您的系统中扮演不同的角色。如 这样，它可以表示为ACL中的多个服务。有 无需为每个ACL服务定义附加服务 - 它们 已经是服务了。
我必须承认，我还没有听过 Udi的制作角色，所以我有点迷失在这里，但我并不是在暗示我们应该为我们已经拥有的每个 ACL服务添加额外的 ACL服务。相反，我问的是作者是否意味着我们应该为每个责任提供一个ACL服务（即如果其他 BC / Facade 一个责任，我们应该定义一个单个ACL服务，如果它有两个职责，我们应该定义两个ACL服务等）
4）
正确。然而，两个BC之间的关系在当地发展 可能与外部系统不同。
不同如何？
第二次更新：
1）
a）
II。
Facade封装了外部系统的API。如果 API提供的功能仅由单个BC使用 有多个用例，那么只有一个外观是可以的 为BC服务。另一种方法是为每个人创建一个立面 用例。这也很好，但就像我说的那样，技术凝聚力 第一种方法可能是有益的。
Q1 - 您正在使用术语＆＃34; 用例＆＃34;而不是责任。我是否正确地假设说＆＃34; 一个Facade暴露了一个用例＆＃34;通常建议 Facade公开一个方法，同时说＆＃34; 一个Facade公开一个责任＆＃34;也可能意味着 Facade暴露了几种方法（它们共同完成了一项特定任务）？
Q2 - 那么 Facade 是否应公开责任或用例？
诉
通常，功能性凝聚力优于技术性或逻辑性 凝聚。但是，一般情况下，您将混合使用两者。技术 凝聚力可以在较小的尺度上方便。例如，您可以使用 门面中类似的序列或翻译机制。它是 方便在外墙之间分享，但不是以牺牲为代价 功能凝聚力。因此，可以共享这样的功能 在一个BC内，但不在BC之间。
从远处开始，单一Facade 具有技术凝聚力而不是功能凝聚力是有意义的。但是这个过程在实践中看起来相当混乱。为了解释，假设外部系统公开了几个职责，那么我们可以设计 Facade ，使其具有技术凝聚力而不是只需通过单一Facade 公开外部系统提供的所有职责，功能凝聚力。
但是，当外部系统（因此 Facade ）仅暴露单一责任时，我想象一个场景会有更多困难 - 甚至在这样的场景中，可以设计一个 Facade ，使其具有技术凝聚力而不是功能凝聚力？如果是的话，你能提供一个简单的例子吗？
VI。 功能凝聚力与副作用自由功能 / 纯函数有什么关系？
2）
b）中
无论如何，ACL服务如何映射到Facade？也许每个ACL服务 映射到我们的Facade公开的一个责任（即Facade 暴露单一责任，然后我们只有一个ACL服务，如果 它暴露了两个职责，我们有两个ACL服务等）？
ACL是由服务组成的外观。是的，你的假设 是一种可以接受的方式。这里的术语“外观”并不意味着什么 引用单个类，但是一组类（服务） 包括反腐败层。它可能只是一个类，或者它 可能很多。
予。我想我理解你所暗示的，但只是为了确定 - 假设我们的BC 只与一个外部系统进行通信，因此我们只有一个Facade ，是一个 Facade ，通常是作为单一类实现的？
II。顺便说一句，我认为 ACL服务不直接调用此Facade ，而是调用相应 Adapters <的方法 / em>，然后在此Facade 上调用方法？
III。
是的，你的假设是可以接受的方式。
所以，您基本上建议如果外部系统公开两个职责，我们应该有一个单个Facade 公开这两个职责，但另一方面，我们应该有两个ACL服务，每个责任一个？
第三次更新：
你的回答让我非常困惑，所以在我能够回答你的答案（在这个和我做的其他话题中）产生任何有意义的问题之前，我必须问你以下内容：
据我了解您的答案，您似乎基本上说 ACL服务构成 Facade ，这意味着这些ACL服务代表Facade的界面？这也意味着 Facade属于我们的BC ，因为它是用我们BC的域模型来表达的（原因是 ACL服务 em>用我们BC的域模型表示？）
但Evans声称 Facade 属于其他系统的 BC （因此应该使用外部系统的域概念表示） ），而 ACL服务应属于我们的BC ，因此应使用我们BC的域概念表示：
PG。 367：
Facade属于其他系统的BC
我是否误解了你的帖子，或者你对这个主题的看法与埃文斯的意见有点不同？
谢谢
答案 0 :(得分：2)
1a）如果外观由同一个项目使用，并且不同的职责仍然属于同一个有界的上下文，那么使用相同的外观。沿着外部系统API轴的技术凝聚力的好处将超过沿责任轴的功能耦合的好处。
1b）外观本身实际上是一种服务或一组服务。无需定义其他服务。
2a1）是的。
2a2）是的，但是我不会说在贬义的意义上泄漏。 ACL的目的是使外部模型适应本地域模型。因此，自然地，领域概念将存在。
2b）ACL服务只应在外部系统和BC之间进行调解。然而，这种调解的性质可以延长。中心目标是防止外部模型变化导致的腐败。
3）是的，外部系统可能在您的系统中扮演不同的角色。因此，它可以表示为ACL中的多个服务。无需为每个ACL服务定义附加服务 - 它们已经是服务。
4）正确。然而，本地开发的两个BC之间的关系可能与外部系统的关系不同。
<强>更新
1a1）是的，错字。校正。
1a2）Facade封装了外部系统的API。如果API提供的功能仅由单个BC使用，但有多个用例，则可以为该BC提供单一外观服务。另一种方法是为每个用例创建一个外观。这也很好，但正如我所说，第一种方法的技术凝聚力可能是有益的。
1a3）在这种情况下，每个BC都会有一个立面。另一种方法是尝试分享立面。正如你所说，这将成为一种依赖性混乱。
1a4）是的。如果其他BC是不同app的一部分，请按照1a3中的说明创建特定于BC的新外观。
1a5）通常，功能cohesion优于技术或逻辑凝聚力。但是，一般情况下，您将混合使用两者。技术凝聚力在较小规模上可以很方便。例如，您可以在外观中使用类似的序列或转换机制。在外墙之间分享这些是很方便的，但不是以功能凝聚力为代价。因此，可以在单个BC中共享此类功能，但不能跨BC。
2b）ACL是由服务组成的外观。是的，你的假设是可以接受的方式。这里的术语“外观”并不是指单个类，而是指包含反腐败层的类（服务）集。它可能只是一个类，或者可能很多。
3）是的，这是作者所说的。
4）这也将在本书的后续部分讨论。本地BC的不同之处在于，开发它们的团队可以进行沟通，并调整其模型以满足另一个的要求。对于外部BC，这可能是不可能的。
更新2
1a1）“用例”一词旨在与“责任”互换。它们可能意味着一种方法或一些方法。
1a2）我认为责任是一个更好的术语。
V。）外部系统当然只能提供单一功能。例如，您可以使用第三方服务返回货币的汇率。它只有一种方法，并且ACL将用于管理货币和汇率在不同系统中的表示方式的差异。然而，在这种情况下，你并没有考虑凝聚力，因为你只有一个责任。
VI。）不。它只是一种cohesion，与手头的领域保持一致，而不是某些技术方面。
2b1）你有一个实现域服务的类，它将外部BC暴露给本地BC。但是，这个类可以使用其他类，例如序列化或其他类。然而，这些类“隐藏”在这个服务类后面。
2b2）ACL服务构成了外观。这可能只是术语上的混乱。 ACL是一个门面。
2b3）你可以让一个服务公开这两个职责。通过这种方式，您可以轻松地共享一些代码 - 技术凝聚力。但是，您也可以将共享代码提取到可由两个不同服务使用的实用程序类中。我所说的只是第一种方法并不可怕，因为你仍然局限于一个BC。