业务架构 序列8 到底啥叫“领域模型”？

在

业务架构 序列7 到底啥叫“建模”？

，我们探讨了什么叫做“建模”（也就是什么叫做“模型”）。而本篇，将对“领域模型”这个最最基础，也很抽象的东西做一个深入探讨。

“领域模型”，是在“模型”前面加了2个字，领域。从字面上来看，领域模型，是模型的1种。

一、什么叫做“领域”？

领域是你所面对的“业务问题空间”，注意，是“业务问题”，而不是“技术问题”。

比如你要用什么样的DB，什么样的缓存，怎么“分库分表”，API接口设计，消息中间件的生成/消费策略，这些都是“技术问题”。

所谓业务问题，是指你的系统，如何很好的处理业务需求、业务规则。业务需求一直增加，并且不断变化，系统如何应对？

比如你做电商，C2C, B2B, B2C, B2B2C。。玩法五花八门，各式各样，你的系统如何支撑？

比如你做广告，CPC, CPM, CPT, 搜索，推荐，。。玩法五花八门，各式各样，你的系统如何支撑？

二、什么叫做“领域模型” -- “道”的层面

如果说“领域”是“问题”； 那么“领域模型”，就是为这个问题，开出的“答案”。

领域，也就是现实世界的业务，是复杂多变的，你看到的是现象；

而领域模型，就是要找到这些现象下面的不变的部分，也就是本质。

找到了“现象”背后的“本质”，变化背后的不变性，也就找到了“问题”的“答案”。

三、什么叫做“领域模型” -- “术”的层面

在《领域驱动设计》一书中，引入了一序列概念：实体/值对象/聚合根/领域事件/Specification。

就像任何一门语言，最基本的是单词；同样的， 领域驱动设计的这些概念，也就是领域模型这门建模语言的单词。有了单词，你就可以组装成句子，组装成段落，组装成文章。

这些概念，其实也就是给了你一系列的分析工具，帮助你分析出“领域”这个现象背后的“本质”：

你的领域里面有哪些核心实体？ 这些核心实体又由哪些子的核心实体组成？

核心实体之间是什么关系？

除了核心实体，是否还有某些核心的事件？ 核心的业务规则，算法？

四、领域模型的变通与折中

虽然领域驱动设计（DDD）这个方法论从出现到现在已经十几年了，但其实它一直是一门“隐学”。

在中国，很少公司会严格遵循DDD的方法论进行设计和编码，这其中原因很多，不在此逐一展开。

因为在DDD之外，有很多更传统/更经典的方法论，比如数据库的ER模型、UML(面向对象的OOA/OOD/OOP)，再到分布式的服务化（微服务架构）。

这些方法论，个人认为，在思路上面，与DDD其实很多相似地方。这也是我在另外一篇文章：《领域驱动设计的6步成诗法》里面谈到的，DDD其实是一个集百家之所长的方法，而不是一个单一的方法论。

所以在实践中，大家并不会强行限制说自己用的是哪一种方法论，而是根据自己的业务和团队，选择了某种杂糅的方式，可能用ER模型图 + UML + DDD的某些概念 + 微服务架构。。。

这比较符合中国人的实用主义思维，反正不管黑猫、白猫，能抓住问题并解决问题的就是好猫。