DDD 必备架构--六边形架构 _DDD

架构是研究“分”和“合”的艺术，通过“分离关注点”将系统拆分为多个部分，然后在“原则和规则”的约束下对组件进行装配，形成高内聚的构件；再根据需求对多个构件进行关联，形成低耦合的连接，最终构建“高内聚低耦合”的软件系统。

文章插图

image
为了有效应对软件复杂性，通常会对其进行分类，然后对症下药逐个击破。
1. 软件系统复杂性面对一个软件需求，我们经常会将其分为两类：

功能性需求。就是产品提出的众多业务功能，例如：用户登录、查询数据、添加订单等；
非功能性需求。指系统在实现功能时必须满足的技术指标，最常见的包括性能、可靠性、安全性、可维护性、易用性等，例如：系统的响应时间、并发访问量、容错能力、数据安全性、可扩展性等。

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

面对不同的需求和复杂性，其设计目标和应对方式也完全不同。
1.1. 业务复杂性首先，看下业务复杂性：

文章插图

image
对于业务需求，我们追求的是系统的复用性和扩展性。

复用性。指组件或模块能够在不同的场景下被重复使用。高复用性设计能够大幅度减少开发和维护的成本，提高开发效率。组件的粒度越小复用性越高，功能结构越清晰，逻辑调整越便利，与之相反的是代码重复率，重复代码是系统腐化的重要标志；
扩展性。能够在不改变现有系统结构的情况下，方便地添加新的功能或修改现有功能。具有高扩展性的系统能够满足未来需求的变化，降低系统的维护成本。

导致业务代码变化的原因有很多，比如：

线上bug 。线上bug很少但对业务系统的伤害巨大，发现bug后为了快速修复问题，往往选择短平快的方式而非最佳方案，这些“补丁”就像系统中的“飞线”在代码中穿梭，成为超出三界的定时炸弹，一不小心就会给你意外的“惊喜”；
新功能需求。这是代码膨胀的主要推动力，开发人员将产品提出的需求翻译成代码，不停的“塞入”到代码仓库，导致仓库快速膨胀，很快你将面对几十万行代码并在之上进行新的开发；
创新性业务。意味着新建系统、新建仓库、新建服务，看起来一切非常良好，可以一次性甩掉多年的历史包袱，但公司整个系统变得越来越复杂，甚至没人能说出服务间的调用关系；

这些变更都会导致业务代码越来越多、逻辑越来越复杂，最终变得难以维护。
【DDD 必备架构--六边形架构】为了更好的应对这些变化，常见的手段包括：