什么是实体边界交互器架构

实体边界交互器Entity—Boundary—Interactor（EBI）源自Bob大叔在其题为“ Architecture：The Lost Years” 及其 着作的 系列会谈中最初构想的想法。

EBI架构是一种适用于各种应用程序样式的现代应用程序架构。它特别适用于Web应用程序APIS，但EBI的概念是生成与实现无关的体系结构，它不依赖于特定的平台，应用程序，语言或框架。这是设计程序的一种方式，而不是库。

名称Entity-Boundary-Interactor源于 硕士论文 ，深入研究了这种架构。常见或同义的名称是EBC，其中C代表Controller。

通常在查看Web应用程序的代码时，您会看到大量的文件夹，库安装和 工具 配置。代码随意地构建到非描述性文件夹中，并且应用程序的依赖关系布局是一个丛林。

结果，程序的目的和架构变得不透明。

应用程序的体系结构由其用例驱动。-Ivar Jacobsen

我们的想法是设计程序，以便他们的架构能够立即呈现其用例。这是一种设计程序的方法，以便它的内部依赖图被清晰地组织起来，并且它的元素以尽可能松散的耦合连接在一起。

最终，目标是在应用程序层之间分离关注点，这种架构和许多类似于它不依赖于表示模型或平台。所有箭头或依赖关系都指向抽象链中的内部，每个连续的层都比之前的那个更抽象。

与MVC有什么不同？

EBI和MVC之间的区别在于EBI体系结构是应用程序的业务逻辑被设计为与其交付机制无关的平台。

换句话说，这意味着业务逻辑部分，交互者和实体不知道他们从哪个媒体访问。它可以来自Web服务器，单元测试或GUI应用程序。

将此与MVC形成对比，MVC 总是依赖于传递机制。无论你怎么努力，你都无法将Rails控制器从网络世界中剔除。

架构

该架构最好描述为功能性数据驱动 架构，其中请求被处理成结果。该架构由三个不同的组件组成。

• 实体Entity是架构的核心。实体表示具有独立于应用程序的业务规则的业务对象。他们可能是Book在图书馆或Employee员工登记处。所有与应用程序无关的业务规则都应位于实体中。
• 边界Boundary是与外界的联系。边界可以实现用于处理图形用户界面或web API的数据的功能。边界本质上是函数性的：它们接受数据请求并产生响应。这些抽象由交互者具体实现。
• 交互者Interactor操纵实体。他们的工作是通过边界接受请求并操纵应用程序状态。Interactors是应用程序的业务逻辑层：交互者根据请求行事并决定如何处理它们。交互者知道称为DTO的数据传输对象的请求和响应模型。交互者是边界的具体实现。

优良作法是将EBI架构本身分为五个不同的层。这些层对应于您选择的语言的命名空间或包。

• 在主机层实现了API的物理表现，例如Web服务器
• 该API层是接口程序本身，它接受输入，并将其转换成的DTO，将它们传递给
• 包含边界，响应 和请求模型的服务层
• 该核心包含具体的服务实现层的层
• 实现边界并形成应用程序核心业务逻辑的交互者
• 表示程序数据模型的实体

因此，在构造程序时，使用依赖注入从上到下构建API。该主机层是一个做具体作用因子的DI。

就是这样: 交互者不知道其请求来自哪个协议或被发送到哪个协议，并且API不知道什么类型的交互器实现服务边界。

详细点击标题见原文！