DDD[1]·区分系统与业务行为

初学 DDD 一定会看到各种分层架构，大量的名词堆砌: 域、限定上下文、聚合等等，当还没有理解这些东西的时候，又来了事件风暴、领域拆分、领域事件等各色名词。

DDD 不就是 「通过 EventStorm 建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义合理的分层架构思想的代码结构模型，从而保证业务模型与代码模型的一致性的一种编程技术」么，这有什么难理解的？

于是当我试图向别人讲解什么是 DDD 的时候陷入了沉思。

我尝试用更简单的描述让人理解 DDD，那就是: 区分系统与业务行为。

比如查询数据库记录就是系统行为，用户登录是业务行为，查询数据库记录只是实现用户登录的一种手段。

举个例子🌰

#这就是一个系统行为的操作, 在数据库里查找数据conn = mongo.mongo_async_connection()class MongoMixin:    _name_database = ''    __name_collection = ''    async def find_one(cls, **kwargs):        db = conn[cls._name_database]        collection = db[cls.__name_collection]        result = await collection.find_one(kwargs)        return cls.instance_from_dict(result)
#这是一个语义化的接口, 并且有自己的业务逻辑#即使不再使用当前的数据库也可以方便的替换class User(MongoMixin):    async def login(cls, name, password):        password = salt(password)        return await super().find_one(name=name, password=password)

方法 find_one 是一个 mongo 的 mixin，这样的一个 find_one 是可以被任意的业务实体所使用的。

再举个例子🌰

MySQL 之类的关系数据库在使用的时候，添加字段是比较麻烦的，需要做数据库变更+代码修改，一般会预留一个 feature 的字段，方便存储没有查询需求的数据，在业务上可能是一些数据标识、冗余等

须知这只是数据库的一个设计手段，和业务是没有关系的

在业务代码中不应该出现任何的 featureAdd 或者 featureRemove 的代码，仅在落库的时候体现出来这个设计

当你写业务代码能意识到这个问题的时候，实际上我们就提出来一组概念:

领域模型 & 数据模型

领域模型承载业务行为，数据模型承载系统行为，领域模型是核心，数据模型是技术细节

领域模型表达业务语义，比如 login 是一个典型的业务语义方法

数据模型关注的是拓展能力，比如会使用 feature field 的技巧

再补充一些例子:

在实际的业务场景中，会存在一些常见的分组关系，比如主子账号，分 P 视频，主子订单等等

在数据模型上为了实现这种关系，就是经典的 树形结构库表设计 问题

看完这篇文章，想必你在编程的时候会不自觉的开始区分业务行为与系统行为