1)
a) ACL Facade仅提供对我们BC需要的其他系统（外部系统，甚至可能是我们团队开发的另一个有界上下文）的那些功能的访问。如果其他系统公开了我们可以分类为几个不同职责的功能（我们的BC感兴趣），我们应该为这些职责中的每一个定义一个ACL Facade ，还是应该让单个ACL Facade公开所有职责（由外部系统提供）我们的公元前需要？
b) 如果对a)的回答是我们应该为外部系统提供的每个职责定义一个 ACL 外观，我们是否应该反过来也为每个 ACL 外观定义一个 ACL 服务？！
2)
a) 埃文的书（第 366 页）：
AntiCorruption 层的公共接口通常显示为一组服务……在我们的模型中，将外部系统表示为单个组件甚至可能没有意义。最好使用多个服务，就我们的模型而言，每个服务都有连贯的责任
ACL本身并不驻留在域层中，但是根据上面的引用，ACL 服务不代表域概念吗？如果是这样，我们难道不能这样说：
I- ACL 服务是域服务吗？
II -域概念已泄漏到ACL中？
b) ACL 服务的职责是什么？仅仅是在我们的BC和外部系统（即其他BC）之间进行调解，或者ACL Service是否可以承担与外部系统提供的责任不同的责任，因此ACL Service只能使用外部系统提供的功能来执行它自己指定的任务。 ?
3) 埃文的书（第 366 页）：
AntiCorruption 层的公共接口通常显示为一组服务……在我们的模型中，将外部系统表示为单个组件甚至可能没有意义。最好使用多个服务，就我们的模型而言，每个服务都有连贯的责任
作者是否说将外部系统表示为具有单一职责可能没有意义，但该系统可以表示为具有多个职责，因此我们将为每个职责定义ACL Facade + ACL 服务（和相应的适配器）这些责任？
4）顺便说一句-我假设ACL也可以在同一个应用程序中存在并由同一个团队开发的两个有界上下文之间定义？
更新：
1)
a）我不太明白你的推理：
如果外观被同一个项目以不同的职责使用仍然属于相同的有界上下文，则使用相同的外观。沿着外部系统 API 轴的技术凝聚的好处将超过沿着责任轴的功能耦合的好处。
一、我认为“ at ”是一个错字，应该用“和”代替？
二、通过“不同的职责仍然属于相同的有界上下文”，您是指Facade仅公开单个BC的职责这一事实吗？
三、如果Facade暴露了几个 BC的职责，那么我们应该为每个外部 BC设置一个 Facade吗？如果是，为什么它比为所有BC拥有一个 Facade 更可取？仅仅因为Facade 界面会变得一团糟？
四。“如果外观被同一个项目使用”是指如果两个 BC都是同一个应用程序的一部分，那么我们应该使用单个外观来公开所有职责吗？如果另一个BC属于不同的应用程序怎么办？
五。
沿着外部系统 API 轴的技术凝聚的好处将超过沿着责任轴的功能耦合的好处。
为什么技术内聚优于功能耦合？
b)
外观本身实际上是一个服务或一组服务。无需定义额外的服务。
嗯，我不确定我是否理解这一点。无论如何， ACL 服务如何映射到Facade？也许每个 ACL 服务都映射到我们的Facade暴露的一个职责（即，如果Facade暴露了一个职责，那么我们只有一个 ACL 服务，如果它暴露了两个职责，我们就有两个 ACL 服务等）？
3)
作者是否说将外部系统表示为具有单一职责可能没有意义，而是该系统可以表示为具有多个职责，因此我们将为每个职责定义 ACL Facade + ACL 服务（和相应的 Adapter ）责任？
是的，外部系统可能在您的系统中扮演不同的角色。因此，它可以在 ACL 中表示为多个服务。无需为每个 ACL 服务定义额外的服务 - 它们已经是服务。
我必须承认我还没有听过Udi 的 Making Roles explicit，所以我有点迷失在这里，但我并不是暗示我们应该为我们已经拥有的每个ACL 服务添加额外的ACL 服务。相反，我问的是作者是否意味着我们应该为每个职责设置一个 ACL 服务（即，如果另一个BC/Facade有一个职责，我们应该定义一个ACL 服务，如果它有两个职责，我们应该定义两个 ACL 服务等）
4)
正确的。但是，本地开发的两个 BC 之间的关系可能与外部系统的关系不同。
不一样怎么办？
第二次更新：
1)
一个）
二、
外观封装了外部系统的 API。如果 API 提供的功能仅由单个 BC 使用，但有多个用例，则可以为该 BC 提供单个外观服务。另一种方法是为每个用例创建一个外观。这也很好，但就像我说的，第一种方法的技术凝聚力可能是有益的。
Q1 - 您使用术语“用例”而不是Responsibility。我是否正确假设说“一个外观暴露一个用例”通常表明外观暴露一个单一的方法，而说“一个外观暴露一个单一的责任”也可能意味着外观暴露了几个方法（它们一起完成一个特定的任务 ）？
Q2 - 那么外观应该暴露职责或用例吗？
五。
通常，功能凝聚力优于技术或逻辑凝聚力。但是，通常，您将两者混合使用。技术凝聚力可以在较小的范围内方便。例如，您可以在外观中使用类似的序列化或翻译机制。在立面之间共享这些很方便，但不会以功能凝聚力为代价。因此，可以在单个 BC 内共享此类功能，但不能跨 BC 共享。
从远处看，具有技术凝聚力而不是功能凝聚力的单一立面是有意义的。但是，这个过程在实践中的样子会变得相当混乱。解释一下，假设外部系统暴露了几个职责，那么我们可以设计Facade，使其具有技术凝聚力，而不是功能凝聚力，只需让一个Facade暴露外部系统提供的所有职责即可。
但是当外部系统（以及Facade）只暴露一个单一的责任时，我很难想象一个场景——即使在这样的场景中，是否有可能设计一个Facade，使其具有技术凝聚力而不是功能凝聚力？如果是，你能提供一个简单的例子吗？
六、功能凝聚力是否与无副作用功能/纯功能相关？
2)
b)
无论如何，ACL 服务如何映射到 Facade？也许每个 ACL 服务都映射到我们的 Facade 公开的一个责任（即，如果 Facade 公开一个责任，那么我们只有一个 ACL 服务，如果它公开两个责任，我们就有两个 ACL 服务等）？
ACL 是由服务组成的外观。是的，您的假设是一种可以接受的方法。这里的门面一词并不是指单个类，而是指组成反腐败层的一组类（服务）。它可能只有一个类，也可能是多个类。
I. 我想我理解你的意思，但只是为了确定——假设我们的 BC只与一个外部系统通信，因此我们只有一个 Facade，一个Facade通常实现为一个类吗？
二、顺便说一句，我假设ACL 服务不直接调用这个 Facade，而是调用相应Adapters的方法，然后调用这个 Facade上的方法？
三、
是的，您的假设是一种可以接受的方法。
所以你本质上是在暗示，如果外部系统暴露了两个职责，我们应该有一个单一的 Facade暴露这两个职责，但另一方面我们应该有两个 ACL 服务，一个用于每个职责？
第三次更新：
你的回答让我很困惑，所以在我提出任何有意义的问题来回应你的回答（在这个和我提出的另一个主题中）之前，我必须问你以下问题：
据我了解您的回答，您似乎本质上是在说ACL 服务构成了Facade，这意味着这些 ACL 服务代表了Facade 的接口？这也意味着Facade 属于我们的 BC，因为它是根据我们的 BC 的域模型表示的（原因是ACL 服务是根据我们的 BC 的域模型表示的）？！
但是 Evans 声称Facade属于另一个系统的 BC（因此应该使用外部系统的域概念来表达），而ACL 服务应该属于我们的 BC，因此应该使用我们 BC 的域概念来表达：
pg。367：
Facade 属于另一个系统的 BC
那么我是否误解了您的帖子，或者您对这个主题的看法与埃文斯的看法有些不同？
谢谢你