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

19-01-09 banq
                   

实体边界交互器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不知道什么类型的交互器实现服务边界。

详细点击标题见原文!