Api容器在应用架构演化中的用途

单层架构

在最开始编程的时候相信你们都写过下面这种架构,界面代码，业务代码，数据库链接所有在工程面完成。固然这种架构在处理很小的程序的时候依然有生命力

两层架构

后来咱们发现数据访问的代码大量重复，应该进行抽象，因而单独将数据访问相关的代码封装出一个数据访问层，就是用Sqlhelper将数据库访问的方法封装，用DataTable返回到ui之中使用。

三层架构

随着业务规模的增长，UI层代码愈来愈多,而且有大量逻辑重复的代码，因而将UI曾中业务逻辑代码抽象出一层，放到BLL中，UI只处理一些界面展现，跳转，参数校验等相关内容，可是此时咱们用的数据结构大部分状况下仍是放在一个集中的工程Data中。

单个领域分层

当业务复杂度继续提升的时候，你会发现以下问题：

1. 服务之间有大量重复的代码
2. 修改一处业务须要改动多个地方的代码
3. 服务会引用服务
4. 服务之间关系很是混乱
5. 甚至会出现相互引用的状况

在领域中运用以下战术设计解决上述问题

1. 通常解决重复代码的思路都是将代码下沉(放到分层结构的更下面的层)，可是随着复杂度的增长，一样会出现重复的问题，在领域驱动设计中，是将业务逻辑放到实体中，而实体是用来承载数据，能够说是最底层。这样就解决了重复代码的问题。
2. 将业务逻辑封装到领域以后，逻辑集中后修改起来也比较方便
3. 由于业务逻辑都在领域层因此服务直接的依赖变成服务和领域层的依赖
4. 实体之间的逻辑是经过聚合根或者领域服务来组织。
5. 原来的BLL层变成Application层。基本上一个应用服务的接口对应一个业务用例。由应用服务来调用领域处理业务，同时处理业务以外的一些技术和交互逻辑：例如 持久化,上下文交互等等

多个领域分层

随着对业务的理解，会造成一组一组这种概念(领域的划分)。

单进程多领域六边形架构

若是咱们引入领域驱动中六边形架构以后(六边形架构其实能够认为是领域分层的一种实现方式):

1. 此时将Application的契约和实现分离到不一样的项目之中。
2. 对六边形内部的访问都必须经过契约来调用

Api容器的多进程改造

一个六边形理解为一个模块

1. 进程间通讯使用Http
2. 将全部模块的Contract组织到一块儿(每一个Contract依旧是一个项目)
3. 将原来的契约，契约实现，领域，仓储实现，放到容器之中
4. 调整工程间的依赖关系保证模块和模块，ui和模块之间没有相互应用
5. UI和其余模块，只需利用ioc将实现注册到契约修改为客户端代理注册到契约便可.

总结

恰如其分的架构中提到三种设计方式：

1. 演进的设计: 知足客户现有需求，追求快速编码快速实现。
2. 计划的设计：考虑将来扩展，保证开发过程有条不紊
3. 最小化设计: 作适当设计，这是介于演进式和计划式。

最近很流行微服务,都拿微服务和单体架构作对比,可是若是初期就设计一个微服务那么架构和维护成本过高，不少产品初期团队根本不具有这样的资源，可是若是开始就设计一个单体架构可能又知足不了将来业务的发展.若是微服务架构是一个计划式设计的话，那单体架构就是一个演进式架构。可是这种演进的成本很高，甚至面临着重作的风险。

若是咱们引入六边形架构这种最小化设计，再结合api容器就能够几乎0成本的将单体架构切换到微服务.

PS:每一个架构演化均可以说不少，网上已经有不少这种说明，这里就没有详细的说明，有兴趣的能够留言讨论.