架构是研究“分”和“合”的艺术，通过“分离关注点”将系统拆分为多个部分，然后在“原则和规则”的约束下对组件进行装配，形成高内聚的构件；再根据需求对多个构件进行关联，形成低耦合的连接，最终构建“高内聚低耦合”的软件系统。
为了有效应对软件复杂性，通常会对其进行分类，然后对症下药逐个击破。
面对一个软件需求，我们经常会将其分为两类：
其实，这两类需求整好与软件系统的两类“复杂性”一一对应：
面对不同的需求和复杂性，其设计目标和应对方式也完全不同。
首先，看下业务复杂性：
对于业务需求，我们追求的是系统的复用性和扩展性。
导致业务代码变化的原因有很多，比如：
这些变更都会导致业务代码越来越多、逻辑越来越复杂，最终变得难以维护。
为了更好的应对这些变化，常见的手段包括：
业务复杂性先简单介绍到这，接下来看下技术复杂性：
对于非功能需求，我们追求的是系统的高性能和高可用。
导致技术复杂性激增的原因有很多，比如：
这些问题并不能通过简单的增加代码来解决，往往需要引入新技术或使用新方案：
通过对比，是否有一种感觉：“业务”与“技术” 差距巨大，可以说是天壤之别。所以需要一种架构，能够对 “业务” 和 “技术” 进行隔离，降低两者的相互影响，使得：
六边形架构，便可以解决这个问题。
六边形架构出自《实现领域驱动设计》一书，与“洋葱架构” 非常相似，都能很好的实现 “业务” 与 “技术” 的分离。
在 “Command侧”（详见CQRS架构） DDD 仍旧是最佳解决方案，所以在此使用 “六边形架构” 作为顶级架构。
六边形架构如下：
内六边形聚焦于业务逻辑，使用良好的设计应对业务的复杂性；通过提升系统的复用性和扩展性，来应对未来的变化。
DDD 是解决复杂业务的一把利器，将业务需求和代码实现相结合，通过对业务领域的深入理解，构建出可复用、可维护、可扩展的领域模型。
DDD 分为战略和战术两部分，在此重点阐述战术部分。战术模型主要包括：
这些领域对象相互协作，共同承载复杂的业务场景，大幅提升了业务的复用性和扩展性。
也称为测试驱动开发，它的基本思想是在编写代码之前先编写测试，然后根据测试来编写代码，最后再运行测试。可以帮助开发人员更快地发现并修复代码中的bug，还可以让开发人员更加关注代码的设计，使代码更加健壮、可扩展和易维护。
业务模型与基础设施的解耦将为你的 TDD 带来众多好处：
两顶帽子法，将软件变更落地过程分为两个阶段：
外六边形聚焦于技术，与公司基础设施密切相关，也受所用框架的各种约束。其核心是发挥框架和中间件的优势，更好的为业务提供服务。
根据应用场景的不同，我们将外六边形的组件分成两类：
他们是系统与外部的“翻译官”，将外部请求转换为系统可以理解的指令，并将系统响应转换为外部世界可以理解的格式，这种松耦合可以使系统更加灵活更具扩展性。
常见的输入适配器主要包括：
常见的输出适配器主要包括：
这么多纷繁复杂的框架、中间件从另一个层面也验证了，外六边形是以技术作为驱动的，其核心就是：如何更好的使用这些技术工具，发挥每个框架的强项。
任意一个业务系统都会面对两类需求：
两类需求背后的驱动力（复杂性）完全不同：
为了更好的应对这两类变化，需要在架构上进行隔离，避免相互影响带来更多的复杂性，然后逐个击破。这就是六边形架构最擅长的领域：