六边形架构

前言

注: 当我在学习DDD时，看到其中的六边架构，在初步了解其架构思想以后，就深深地被吸引了，由于它能够解决诸多我在项目中遇到的问题。

这里将着重介绍六边形架构的思想，以及其解决的问题，并不与其它架构作深刻的对比。

六边形架构 又被称之为ports&adpers(我认为这个名称更合适)，是 Cockburn在2005年提出的，目的是为了解决业务逻辑与输入输出的解耦。

架构思想

想像一下电脑如何与周边设备如何交互的：

周边设备有耳机、键盘、外接显示器、耳机等，它们经过电脑的USB、HDMI等端口进行链接；但有时刚买来一个新的设备(好比打印机)，想经过USB与电脑链接，但你插上时，电脑却提示你没法识别，须要安装驱动，你按照说明，安装好驱动就可使用了。并且比较神奇的是，我有两个鼠标，一个是ps/2接口，一个是USB接口，但插上去均可以用， 这是由于系统中安装了两种接口类型的驱动（适配器)。

经过上面的描述，咱们知道，电脑与周边设备是经过端口与驱动（适配器）交互的，且只须要有相应的驱动，端口能够和不一样的设备进行交互。

咱们在设计架构和编码过程当中常常犯一个错误，将业务逻辑与外部实体间的交互纠缠在一块儿。好比，在分层架构中，对数据库的访问和外部接口的访问一般放在gateway中，而因为分层构架，只作了业务的职现划分，并未作层次的解耦，形成对于外部的访问成了业务逻辑的内核；一样，对于对外提供的接口，封装在controller中，也是一样的道理。（固然，这里并非说分层架构很差，只是处理问题的角度不一样）。

六边形架构关注的是“外部”和“内部”的差异，内部业务逻辑（Application)与外设（APP,WEB，数据库等）彻底隔离，仅经过Adapter 进行交互。

那Adapter起什么做用呢？它负责将与外设交互的数据（包括命令、query）转化为Application能够理解的信息（业务module）,并经过内部系统提供的接口进行业务逻辑的处理。

说了那么多adpter,那port该如何界定其职责呢？ 咱们知道，电脑上端口定义了设备的通讯协议，只要是相同的端口，不管是什么设备必须遵循这个协议，只是其通讯的内容可能有所不一样。对于软件系统来说，port上端口协议的体现就是api,即业务系统对外暴露的接口，一个端口能够有多个适配器。好比一个系统提供产口的信息的展现，这时候该信息可能须要在app,web或者做为远程服务对外提供产品信息，这时候由Application是提供一个query 接口，并返回一个Product对象，至于要将其转换成app,web或者远程服务json格式，则由adapter来完成。

为何它叫六边形架构呢？六边形的一个边就表明一个端口，但并不表明一个六边型架构就必须有6个端口，其实这和六个边没有任何关系，做者只是为了方便表达本身的思想，将架构画成了六边形，也方便使用者可以在业务架构时，更方便的设计。

这里仍是提醒一下，虽然六边形强调内部和外部的区别，但并不表明咱们不关注外部接口的主被动（对外提供服务，仍是调用外部服务），但咱们能够在实现端口和adapters 时，经过技术来屏蔽这种差别，但却不适合，也不必使用一个彻底相同的端口来屏蔽这种差别。因此通常的六边形架构架构会在左右两端各有端口，左边表明对外提供服务，右边表明调用外部服务。

经过上面的介绍，相信你已经了解了六边形的设计思想。那它这种业务逻辑和外部系统的分离，还给咱们带来什么好处呢？

如上图所示，应用外对提供了两个端口，用户侧API和数据侧API。用户侧API，经过四个适配器为app,http,GUI,ie提供服务；数据侧经过两个适配器（DB和mock）为应用提供适配服务。你们看到这里，可能会有些吃惊，怎么还有mock?

是的，只须要实现data-side端口的的服务均可觉得Application提供数据，对系统来讲并不会感知到服务的差别，也就是说mock和db 能够提供无差别的服务。说到这里你就明白了，不再用将测试用例嵌入到业务逻辑中了，只要实现相应的adapter就能够了，不再用由于业务代码的变更而更改测试用例。为集成化测试提供了很大的方便。

稍后我会补充一个项目案例！！！！

http://alistair.cockburn.us/Hexagonal+architecture