|01 领域模型是什么

领域模型是什么？一句话：“经济基础决定上层建筑”中的“经济基础”，是帮助理解复杂业务领域问题的基石。

有人说：“领域模型是一个商业概念，同行业的企业，一定有内在的共性，是帮助系统分析人员认识现实业务的工具。”领域，即边界的意思，有了清晰的边界，协作才有了利益的基础；模型，即知识体系，深入理解了业务知识，开发才不会走过多的弯路。一般意义上的领域模型是面向软件工程领域的，而现实意义的领域模型则包含了商业模式等广义上的概念。

很多人一上来理解领域驱动设计（DDD），基本都是一头雾水，因为模型设计的初衷并不是围绕性能、架构、分层等软件概念展开的，而是从边界、内聚等抽象概念开始讲起。理解领域模型，并不是通过技术的思维来学习，而是通过不断地实践过程来训练自我的思维意识，进而彻底形成结构化与面向对象的思维方法论。

领域模型并不能直接带来收益，只是辅助我们去理解正在做的事情。

引用百度的说法，“领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。”总结一下，就是“准确描述问题，清晰描述方案”。

如果说软件开发的本质，是从“问题空间”到“解决方案空间”的转化，那么“领域模型”，就是“解决方案空间”的架构，通过抽象的模型，为系统带来统一的认知。

|02 领取模型怎么设计

设计领域模型之前，首先要确定“问题空间”，即对需求进行分析和拆解。值得注意的是，领域模型通常是针对比较大的系统设计而言，如果是日常功能迭代中的小需求，那么只需要根据已经设计好的模型原则，来做对应的开发即可。

需求分析阶段要做的就是确定系统要实现的核心功能是什么，用UML来表达设计意图是非常好的工具。UML通过动静结合的图示，便可以比较清楚的阐述系统的核心职责与过程。

类图：静态，展示了模型中存在的类、类的内部结构以及它们与其他类的关系等；

状态机：动态，对一个单独对象的行为建模，指明对象在它的整个生命周期里，响应不同事件时，执行相关事件的顺序；

时序图：动态，描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

接下来，就是业务建模阶段了。在大多数讲领域驱动的书籍里，都会将领域划分为：领域，子域和限界上下文。领域是一个模型所包含的全部事情；子域是指模型的某个细分部分，根据重要性可以划分为核心、支撑和通用；限界上下文是一个业务边界，边界内的术语都有其特定的涵义，例如银行系统和电商系统中顾客就不是同一个意思。这种划分方式通常是非常灵活的，跟设计者的个人经验有比较大的关系。

将系统拆分完成后，就需要确定子域/上下文之间的关系，以及相互之间的信息如何进行流转，例如：

模型概念

模型属性和属性值

模型之间的关系

最后，就是通过某些具体的方法论，分析具体的模型设计了。设计的方法论也有很多种，例如在用例分析方法中，就是尽可能的收集用例素材，通过例图，以图形化的方式将系统描述成用例、参与者（用户）及其之间的关系；在DODAF中，是采用标准方法，表述“EA的数据和关系类型”的指引，解决复杂系统结构化问题的指引。在四色建模法中，用蓝色表示命令，用红色表示实体，用绿色表示领域事件，用黄色表示补充信息，相关的实体便可以整理到同一个领域中。建模方式有很多种，不论是已有的方法论，或者是通过日常的业务经验积累来设计，只要能将模型描述清楚，都是可用的。

做个总结，就是抛开技术视角，用纯业务的视角来建立模型。但确定的一点是，领域模型的优先级要高于软件解决方案，先有领域建模的整体框架，然后才是将模型映射到软件架构之中。

|03 领域模型的价值

建模是一个团队性的复杂工作，经过长时间的摸索，有几个特点还是可以总结出来：

建模的时候，不要立刻开始设计具体的模型，而是先对业务进行分析和拆解；很多时候，业务人员也不一定非常熟悉业务，前期调研的过程是必不可少的。

为了避免产生歧义，在建模的过程中最好使用统一的术语与工具，例如UML。

学会适应变化，模型本身是会发生变化的，变化的频率取决于业务发展的速度，当下的形态都是某种意义上的中间态。

一个好的软件系统，需要同时在满足业务需求和系统底层架构之前做权衡，产品运营往往不具备技术背景，因此在“做不做”与“怎样做”之间，往往会爆发激烈的冲突。更多的时候，是对同样的概念，双方都有不同的理解，这种GAP不一定是“大到天边”的那种差异，而是针对某些具体的细节发生了误解，但这种细节往往非常致命。这时候，通过模型来反应实际的业务情况，相当于说明书的作用，来与需求方沟通，就会有效的多。

因而，从全局的角度看，领域模型会带来如下的价值：

统一语言：沟通更加顺畅，分歧易于解决；

知识沉淀：通过对业务领域的熟悉过程，能够以模型的方式沉淀下来，对于自己提升与团队传承均有帮助；

保持清晰：在需求沟通时，能够快速明确哪些需求是合理的，哪些是违反业务规则的，可以让业务跑的更快的同时，保持系统结构的清晰。

|04 数字化转型

看完前面的内容，大多数人会有一种疑问，即领域模型适用在哪里？大多数的互联网场景下，用了领域模型，反而会让业务更复杂。其实自Eric Evans在2003年出版《领域驱动设计：软件核心复杂性应对之道》之后，领域模型的概念才深入人心，那会互联网发展的并不充分。而随着近几年越来越多的企业意识到数字化的重要性，如何用数据去驱动特定行业的发展，比如制造业，慢慢的成为了一种潮流。在这种潮流里，革新传统行业的大概率不是从传统行业走出来的人，而是依赖于掌握了数字化技术的人，技术人怎样快速去了解和深入一个陌生的行业呢？领域模型自然就派上了用场。

例如在信息时代常见的生产力工具ERP和MES，能够解决信息化的很多问题，但是对于生产流转的过程掌握，就不那么适用了，尤其是5G之后很多设备也具备了数字化的特征。用以“数据流”为主要特点的新管理系统，去适应和替代原有的生产系统，就显得很有必要。但过去的“数据流”依赖于Hadoop体系及维度模型，这套组织方式套用到过去的管理系统中，会产生很多的不适应性，因而通过领域模型的方式，去抹平技术上的种种差异，为传统VS互联网行业的人达成共识，共同推动系统改造，就创造了基础。