必备架构 DDD

架构是钻研“分”和“合”的艺术，经过“分别关注点”将系统拆分为多个局部，而后在“准则和规定”的解放下对组件启动装配，构成高内聚的构件；再依据需求对多个构件启动关联，构成低耦合的衔接，最终构建“高内聚低耦合”的软件系统。

为了有效应答软件复杂性，通常会对其启动分类，而后隔靴搔痒逐一击破。

面对一个软件需求，咱们经常会将其分为两类：

其实，这两类需求整好与软件系统的两类“复杂性”逐一对应：

面对不同的需求和复杂性，其设计目的和应答形式也齐全不同。

首先，看下业务复杂性：

关于业务需求，咱们谋求的是系统的复用性和裁减性。

造成业务代码变动的要素有很多，比如：

这些变卦都会造成业务代码越来越多、逻辑越来越复杂，最终变得难以保养。

为了更好的应答这些变动，经常出现的手腕包含：

业务复杂性先繁难引见到这，接上去看下技术复杂性：

关于非配置需求，咱们谋求的是系统的高性能和高可用。

造成技术复杂性激增的要素有很多，比如：

这些疑问并不能经过繁难的参与代码来处置，往往须要引入新技术或经常使用新打算：

经过对比，能否有一种觉得：“业务”与“技术” 差距渺小，可以说是大相径庭。所以须要一种架构，能够对 “业务” 和 “技术” 启动隔离，降落两者的相互影响，使得：

六边形架构，便可以处置这个疑问。

六边形架构出自《成功畛域驱动设计》一书，与“洋葱架构” 十分相似，都能很好的成功 “业务” 与 “技术” 的分别。

在 “Command侧”（详见CQRS架构） DDD 依旧是最佳处置打算，所以在此经常使用 “六边形架构” 作为顶级架构。

六边形架构如下：

内六边形聚焦于业务逻辑，经常使用良好的设计应答业务的复杂性；经过优化系统的复用性和裁减性，来应答未来的变动。

DDD 是处置复杂业务的一把利器，将业务需求和代码成功相联合，经过对业务畛域的深化了解，构建出可复用、可保养、可裁减的畛域模型。

DDD 分为策略和战术两局部，在此重点论述战术局部。战术模型关键包含：

这些畛域对象相互单干，独特承载复杂的业务场景，大幅优化了业务的复用性和裁减性。

也称为测试驱动开发，它的基本思维是在编写代码之前先编写测试，而后依据测试来编写代码，最后再运转测试。可以协助开发人员更快地发现并修复代码中的bug，还可以让开发人员愈加关注代码的设计，使代码愈增强健、可裁减和易保养。

业务模型与基础设备的解耦将为你的 TDD 带来泛滥好处：

两顶帽子法，将软件变卦落地环节分为两个阶段：

外六边形聚焦于技术，与公司基础设备亲密相关，也受所用框架的各种解放。其外围是施展框架和两边件的长处，更好的为业务提供服务。

依据运行场景的不同，咱们将外六边形的组件分红两类：

他们是系统与外部的“翻译官”，将外部恳求转换为系统可以了解的指令，并将系统照应转换为外部环球可以了解的格局，这种松耦合可以使系统愈加灵敏更具裁减性。

经常出现的输入适配器关键包含：

经常出现的输入适配器关键包含：

这么多纷简约杂的框架、两边件从另一个层面也验证了，外六边形是以技术作为驱动的，其外围就是：如何更好的经常使用这些技术工具，施展每个框架的强项。

恣意一个业务系统都会面对两类需求：

两类需求面前的驱能源（复杂性）齐全不同：

为了更好的应答这两类变动，须要在架构上启动隔离，防止相互影响带来更多的复杂性，而后逐一击破。这就是六边形架构最长于的畛域：