Api容器在应用架构演化中的用途
单层架构
在最开始编程的时候相信大家都写过下面这种架构,界面代码，业务代码，数据库连接全部在工程面完成。当然这种架构在处理很小的程序的时候依然有生命力
两层架构
后来我们发现数据访问的代码大量重复，应该进行抽象，于是单独将数据访问相关的代码封装出一个数据访问层，就是用Sqlhelper将数据库访问的方法封装，用DataTable返回到ui之中使用。
三层架构
随着业务规模的增加，UI层代码越来越多,并且有大量逻辑重复的代码，于是将UI曾中业务逻辑代码抽象出一层，放到BLL中，UI只处理一些界面展示，跳转，参数校验等相关内容，但是此时我们用的数据结构大部分情况下还是放在一个集中的工程Data中。
单个领域分层
当业务复杂度继续提高的时候，你会发现如下问题：
- 服务之间有大量重复的代码
- 修改一处业务需要改动多个地方的代码
- 服务会引用服务
- 服务之间关系非常混乱
- 甚至会出现相互引用的情况
在领域中运用如下战术设计解决上述问题
- 一般解决重复代码的思路都是将代码下沉(放到分层结构的更下面的层)，但是随着复杂度的增加，同样会出现重复的问题，在领域驱动设计中，是将业务逻辑放到实体中，而实体是用来承载数据，可以说是最底层。这样就解决了重复代码的问题。
- 将业务逻辑封装到领域之后，逻辑集中后修改起来也比较方便
- 因为业务逻辑都在领域层所以服务直接的依赖变成服务和领域层的依赖
- 实体之间的逻辑是通过聚合根或者领域服务来组织。
- 原来的BLL层变成Application层。基本上一个应用服务的接口对应一个业务用例。由应用服务来调用领域处理业务，同时处理业务之外的一些技术和交互逻辑：例如 持久化,上下文交互等等
多个领域分层
随着对业务的理解，会形成一组一组这种概念(领域的划分)。
单进程多领域六边形架构
如果我们引入领域驱动中六边形架构之后(六边形架构其实可以认为是领域分层的一种实现方式):
- 此时将Application的契约和实现分离到不同的项目之中。
- 对六边形内部的访问都必须通过契约来调用
Api容器的多进程改造
一个六边形理解为一个模块
- 进程间通信使用Http
- 将所有模块的Contract组织到一起(每个Contract依旧是一个项目)
- 将原来的契约，契约实现，领域，仓储实现，放到容器之中
- 调整工程间的依赖关系保证模块和模块，ui和模块之间没有相互应用
- UI和其他模块，只需利用ioc将实现注册到契约修改成客户端代理注册到契约即可.
总结
恰如其分的架构中提到三种设计方式：
- 演进的设计: 满足客户现有需求，追求快速编码快速实现。
- 计划的设计：考虑未来扩展，保证开发过程有条不紊
- 最小化设计: 做适当设计，这是介于演进式和计划式。
最近很流行微服务,都拿微服务和单体架构做对比,但是如果初期就设计一个微服务那么架构和维护成本太高，很多产品初期团队根本不具备这样的资源，但是如果开始就设计一个单体架构可能又满足不了未来业务的发展.如果微服务架构是一个计划式设计的话，那单体架构就是一个演进式架构。但是这种演进的成本很高，甚至面临着重做的风险。
如果我们引入六边形架构这种最小化设计，再结合api容器就可以几乎0成本的将单体架构切换到微服务.
PS:每个架构演化都可以说很多，网上已经有很多这种说明，这里就没有详细的说明，有兴趣的可以留言讨论.
