DDD 必备架构--六边形架构( 二 ) _DDD

系统数据量。随着系统数据量不断积累，当单表数据量超过亿级，不管是访问速度还是异常恢复都将面临巨大挑战

机器规模。当机器规模超过一定的阈值，硬件问题将频繁爆发，基本每天都会出现硬件故障，最终成为高可用的阻力

这些问题并不能通过简单的增加代码来解决，往往需要引入新技术或使用新方案：

新技术。当数据库表数据量达到“亿”级出现明显的性能瓶颈时，可以应用分库分表或 TiDB 来解决
新方案。当数据库读压力巨大，可以调整技术方案，使用数据库读写分离、增加缓存等方案解决

通过对比，是否有一种感觉：“业务”与“技术” 差距巨大，可以说是天壤之别。所以需要一种架构，能够对 “业务” 和 “技术” 进行隔离，降低两者的相互影响，使得：

技术调整不影响业务模型
业务调整不能依赖技术

六边形架构，便可以解决这个问题。
2. 六边形架构六边形架构出自《实现领域驱动设计》一书，与“洋葱架构” 非常相似，都能很好的实现 “业务” 与 “技术” 的分离。
在 “Command侧”（详见CQRS架构） DDD 仍旧是最佳解决方案，所以在此使用 “六边形架构” 作为顶级架构。
六边形架构如下：

文章插图

image
该架构由内外两个六边形组成，这也是其名称来源：

内六边形属于业务域，用于应对业务复杂性。
外六边形属于技术域，用于应对技术复杂性。
其中内六边形是整个系统的核心，外六边形依赖于内六边形，而内六边形不依赖于外六边形
内外两个六边形存在清晰的边界，两者相互独立，互不影响，独自演进

2.1.【业务】内六边形内六边形聚焦于业务逻辑，使用良好的设计应对业务的复杂性；通过提升系统的复用性和扩展性，来应对未来的变化。
2.1.1. DDD

DDD 是解决复杂业务的一把利器，将业务需求和代码实现相结合，通过对业务领域的深入理解，构建出可复用、可维护、可扩展的领域模型。

DDD 分为战略和战术两部分，在此重点阐述战术部分。战术模型主要包括：

实体（Entity）：具有唯一标识的领域对象，具有丰富的属性和行为，表示需要持续跟踪的领域概念，比如用户、订单、地址等；
值对象（Value Object）：没有唯一标识的领域对象，具有属性和行为，一般用于表示某一个领域概念，比如金额、邮箱、手机号等；
聚合根（Aggregate Root）：一组由实体和值对象组成的高内聚对象集合，由一个根实体来管理它们，我们也称之为聚合根，比如订单+订单项便组成了一个聚合，其中订单为聚合根；
工厂（Factory）：创建领域对象的一种机制，也是设计模式在 DDD 中的落地，它隐藏了对象创建细节，并保障创建对象的有效性，主要解决复杂对象初始化问题；
存储库（Repository）：提供对领域对象的持久化和检索功能，将领域对象从数据存储细节中分离出来，完成领域对象和存储引擎的解耦；
领域服务（Service）：处理领域对象之间的交互，没有自己的状态，封装了一些业务逻辑，主要用于需要多个领域对象相互协作才能完成的业务场景，比如银行转账；
领域事件（Event）：指在领域内发生的、有意义的、需要被捕捉的事件，主要完成服务内的流程解耦和服务间的系统解耦；

这些领域对象相互协作，共同承载复杂的业务场景，大幅提升了业务的复用性和扩展性。
2.1.2. TDD