Domain driven design 反腐败层'；s立面、服务和SRP

(一)

a） ACL Facade仅提供对BC所需的其他系统（外部系统或甚至是我们团队开发的另一个有界上下文）的功能的访问。如果其他系统公开了我们可以划分为几个不同职责的功能（我们的BC感兴趣），那么我们应该为每个职责定义一个ACL Facade，还是应该让单个ACL Facade公开我们BC需要的所有职责（由外部系统提供）

b） 如果a）的答案是我们应该为外部系统提供的每个职责定义一个ACL Facade，那么我们是否应该为每个ACL Facade定义一个ACL服务

(二)

a） 埃文的书（第366页）：

反腐败层的公共界面通常显示为 一组服务。。。在我们的模型中，这样做甚至可能没有意义 将外部系统表示为单个组件。最好是 使用多个服务，每个服务在 我们模型的术语

ACL本身并不驻留在域层中，但根据上面的引用，ACL服务不代表域概念吗？如果是这样的话，我们难道不能说：

I-ACL服务是域服务吗

II-域概念已泄漏到ACL中

b） ACL服务的职责是什么？只是在我们的BC和外部系统（即其他BC）之间进行调解，或者ACL服务的责任是否与外部系统提供的责任不同，因此ACL服务只能使用外部系统提供的功能来执行其自己指定的任务

3） 埃文的书（第366页）：

反腐败层的公共界面通常显示为 一组服务。。。在我们的模型中，这样做甚至可能没有意义 将外部系统表示为单个组件。最好是 使用多个服务，每个服务在 我们模型的术语

作者是说，将外部系统表示为具有单个职责可能没有意义，但可以将该系统表示为具有多个职责，因此我们将为每个职责定义ACL Facade+ACL服务（以及相应的适配器）

4） 顺便说一句-我假设ACL也可以在同一个应用程序中存在的两个有界上下文之间定义，并且由同一个团队开发

更新：

(一)

a） 我不太明白你的推理：

如果同一项目在不同位置使用立面 责任仍然属于相同的有界上下文，然后使用 同样的外观。沿途技术凝聚力的好处 外部系统API axis将超过功能性API的好处 沿责任轴耦合

I.我假设“at”是一个拼写错误，应该用“and”替换

二,。“不同的责任仍然属于同一个有限的环境”是指Facade只公开单个BC的责任这一事实吗

三、 如果Facade暴露了几个BC的责任，那么我们应该为这些外部BC的每个设置一个Facade？如果是，为什么它比所有BC都有一个单一的正面更可取？仅仅因为门面界面会变得一团糟

四、 “如果facade由同一个项目使用”，您的意思是如果两个bc都是同一个应用程序的一部分，那么我们应该使用单个facade来公开所有责任？如果另一个BC属于不同的应用程序呢

五,

沿着外部系统API的技术内聚的好处 axis将超过沿途功能耦合的好处 责任轴

为什么技术内聚优于功能耦合

（b）

facade本身实际上是一个服务或一组服务。不需要 定义附加服务

嗯，我不确定我是否理解这一点。总之，ACL服务如何映射到Facade？也许每个ACL服务都映射到我们的Facade公开的一个责任（即，如果Facade公开一个责任，那么我们只有一个ACL服务，如果它公开两个责任，那么我们有两个ACL服务等等）

(三)

作者是说，代表一个外部世界可能没有意义吗 作为一个单一责任的系统，而不是那个系统 可以表示为具有多项责任，因此我们 将为定义每个门面+ACL服务（和相应的适配器） 这些责任中的每一项

是的，外部系统可能在您的系统中扮演不同的角色。作为 这样，它可以表示为ACL中的多个服务。有 无需为每个ACL服务定义额外的服务-它们 已经有服务了

我必须承认，我还没有听过Udi明确角色，所以我在这里有点迷茫，但我不是在暗示我们应该为我们已经拥有的每个ACL服务添加额外的ACL服务。相反，我问作者是否意味着我们应该为每个责任提供一个ACL服务（即，如果另一个BC/Facade有一个责任，我们应该定义一个ACL服务，如果它有两个责任，我们应该定义两个ACL服务等）

(四)

对。然而，两个BC之间的关系在本地发展 可能与外部系统不同

怎么不一样

第二次更新：

(一)

（a）

二,

facade封装了外部系统的API。如果 API提供的功能仅由单个BC使用，但 有多个用例，那么就可以有一个外观 为那个卑诗省服务。另一种方法是创建faca