Entity-Boundary-Interactor(EBI)介绍
前言
EBI架构是一种新型的，可以被广泛适配和实现的应用设计风格，特别适合Web应用的API，它不依赖于特定的平台，应用程序，语言或是框架，它是一种设计方式，而不是一个库。官方文档这段描述，外加联想到第一次读restful的介绍，和EBI一样，他们都是一种设计风格。
Entity-Boundary-Interactor这个名字源于一片硕士论文Using EBI Pattern in Conjunction with Service-Oriented Architectures.其中有同义的内容部分EBC，C代表Controller(下面会介绍与MVC架构有何不同)。
Entity-Boundary-Interactor
平时我们阅读自己公司的框架，或是阅读开源框架的Web框架的时候，经常会看到大量的文件夹，库的安装配置（Java的Maven真是劝退我了当时，不是说Maven不好，Go早期版本的包管理更令人发麻，直到有了Go mod），代码被随意的组织到像app这样的描述性文件夹中，很复杂。(读到这里我其实还没有什么感觉，我理解的python中Django和Flask这样的MVT框架都是鼓励以独立的服务为粒度开发，每个服务或是说app拥有自己的model，view，以为了更好的解耦，习惯了这样的模式就感觉还好，但对于不熟悉的可能比较难找吧)
这样的结果就是会导致软件架构的不透明。
EBI的思想就是为了让架构能够立刻展现使用实例，是一种在程序设计的过程中让内部依赖更加清晰，内部元素能够尽可能的解耦（解耦本身不抽象，反正我读的每一个框架，都提到了为了解耦，为了解耦！！）
EBI想分离应用层之间的关注点，EBI以及其他类似设计的架构都不依赖于presentation models或平台，所有的依赖关系都应该指向抽象链的内部，并且一层
这种架构以及许多类似的架构不依赖于表示模型或平台。 所有的箭头或依赖关系都指向抽象链中的内部，在连续的关系层中，每一层都比前一层更加具体。(这里文档中所说的前一层的方向感觉没有指向清楚)
保证架构像内部收敛能够容易让代码更加易于维护，拓展，测试，和重构，但这确实对程序员的实例有硬性的要求，但设计者必须遵循这项设计规则，这是最低限度，也就是说尽可能收敛。
EBI和MVC有什么区别
EBI和MVC的区别在于，EBI架构是应用程序的业务逻辑要被设计成为于平台无关的一种交付机制。
更加具体的说，这意味着业务逻辑，交互者和实体（对应架构中的Entity和Interactor），不清楚他们是从哪里被访问的，它可以来自Web服务器，单元测试，或者是GUI应用程序。（这里有一点微服务的思想）
MVC使用依赖于交付机制，无论如何努力都没办法将Rails controllers从网络中剥离出来。
Rails
由于我也不知道Rails是什么，这边补充一下介绍。Rails是一个Ruby的用于开发数据库驱动的网络应用框架，基于MVC设计模式。
Ruby On Rails的指导原则是”不要重复你自己”(Don’t Repeat Yourself, 或DRY).意思是说你写的代码不会有重复的地方.比如以往数据库的接口往往是类似的程序代码但是在很多地方都要重复用到.这无论是给编写还是维护都造成 了很大的代价
Reference
https://baike.baidu.com/item/rails/10962333?fr=aladdin
https://ebi.readthedocs.io/en/latest/introduction.html#how-does-this-archtecture-differ-from-mvc
