DDD与六边形架构

更新: 3/15/2025 字数: 0 字时长: 0 分钟

面向表开发

有很多开发者都会调侃说，自己的开发架构是面向表开发的一种架构方式。

回忆我们最初些项目时，往往都是先创建表，然后将表数据映射为实体类，接着围绕这个实体类进行开发（也就是面向CRUD去开发）

这种情况其实就是一种面向表开发。

我们整个开发过程始终去围绕着实体类，一切业务最终都转变为对表的CRUD操作。

不难发现，原本面向表开发的流程，一旦出现了复杂的业务（不是单纯的CRUD，需要强逻辑思维，可能联了多张表），我们的MVC架构在处理上很容易就会出现混乱的情况（各各Service互相引用）

为了解决这个问题，我们才引入了DDD以及六边形架构

介于面向表开发的问题，我们采用了DDD架构。

DDD要求我们将一切业务围绕着Domain（领域）进行开发，一切问题转化为领域模型，在通过围绕领域模型的方式来，然后再让领域来驱动我们的软件的整体开发。

正所谓Domain-Driven-Design，一切围绕领域，一切有领域推到出来，领域就是核心。

六边形架构是DDD的一种实践方式，试图通过依赖倒置的形式来完成DDD项目的创建。

六边形架构将Domain层作为核心的模块，我们可以认为，一个简单的DDD项目形式，只需要一个Domain层和一个非Domain层，我们就可以说他是一个DDD架构的形式。

Domain自身用于完成我们的领域事件，他向外提出述求，要一个能够完成自身领域功能的最小类，然后将返回值给出，至于这个数据如何来，又是否要存储，我们的领域统统不关心。

因此，domain会提出大量的需求，比如完成我的业务需要获取某个来自数据库的信息，那么domain就会提出这个需求，但自身实际上并不关心这个需求如何实现，因此就会采用一种依赖倒置的形式，通过接口的形式将需求提出，并由依赖domain的其他层实现该接口来完成domain的需求。

那么什么是一个领域事件呢，我们可以简单的认为与问题强相关的就是领域事件。

比如一个简单的问题：如何将大象关进冰箱？

这就是一个领域事件的完成。

至于如何打开冰箱，如何关上冰箱，我们一律不操心，我们只需要完成这项任务即可。