边界互通限制Java EE

在Java EE中应用（BCE）模式：

@Stateless //1st boundary
public class A {}

@Stateless //2nd boundary
public class B {}

到目前为止，一切都很好，现在，让我们假设出于某种原因，我需要使用B在A上公开的一些服务。因此，A现在看起来像：

@Stateless 
public class A {
    @Inject
    B b;
    //... call some B's methods
}

但是，根据BCE模式所代表的

控制元素可以与其他两种元素进行通信，但是 实体和边界元素不应直接通信

显然，对于JPA实体，它们需要相互通信（否则，“连接”将不可能）。然后，我以一些相关问题结束：

1） 为什么禁止边界之间的通信？

2） 在Java EE下，我们可以使用@Remote interfaces，这还会违反语句吗？：

@Stateless 
public class A {
    @Inject
    RemoteB b; //now uses a remote dependency
}

@Stateless
@Remote(RemoteB.class)//implements a remote interface
public class B {}

---

3） Java EE是如何解决模式的。

首先，我的建议是将体系结构作为构建应用程序的指导原则，但决不能将其作为法律——因此，始终根据您的需要调整体系结构，并根据您的情况采取合理、简单和合适的措施

边界背后的想法是，它是您业务逻辑背后唯一外部可见的契约，可能会发生变化，其细节也会隐藏。保持对其他边界的依赖性尽可能低是合理的，但是控件可以根据需要使用并被许多边界调用

---

Java EE大师之一Adam Bien在他的研讨会上强调了这一模式，并谈到了其中一种模式。另一个。

如果一些边界需要相互交流是一种不好的气味，那么可能您的设计需要重构，例如，提取控件中的常见行为，并在两者中使用。在使用@Remote的情况下，边界不仅与接口高度耦合，还与所使用的DTO高度耦合（DTO总是处于重复状态）。在面向SOA/microservices的体系结构中，如果您需要这种相互通信，您应该选择低耦合，也就是说，使用json/xml消息

javaee允许您使用jax-rs实现低耦合

---

奇怪的是，亚当·边的一份声明让我感到困惑，请查看此链接>，他没有给出解释，你能解释一下为什么不好吗？我不是这方面的专家，但正如我在第2段中所说，你希望边界成为你控制的入口点，但是不要把它们和其他边界联系起来。好吧，我问过亚当·宾，他会在第五次空袭会议上解决这个问题：）>，我会尽快更新这个问题。