日常工作中是否经常遇到产品上线延期？又或者是看似不起眼的功能却要花费大量时间才能实现？还或者是好不容易通过测试环境的产品却常常在生产环境翻车？

如果你所在的公司或者团队产生以上现象就像是家常便饭一样，但你好像能感觉到问题的存在却又无法道破本质，不妨先来学习下领域模型。

什么是领域模型？

领域模型本身是在软件开发全流程中具有战略指导意义的一套方法论。它不光适用于产品经理对于业务的分析洞察，也适用于技术人员对于产品功能的开发。

针对业务复杂或者产品经理本身没有足够业务沉淀的团队来说，最困难最混乱的时期往往发生于业务蓬勃发展的时候。初代的产品，业务闭环可能不是最正确的，实现方式可能不是最优的，但满足初期的业务支撑其实是没有问题的。而在业务蓬勃发展期，就会出现开头描述的那些问题。

对于产品人员来说，领域模型其实是对于业务域的一种描述。在软件开发过程中，采用类图的表现方式（或者其它也行）描述业务域的实体以及他们之间的关系。在软件开发过程中，它所具备的扩展性以及易用性极大提高了生产力。话不多说，直接上例子：

共享出行（业务初期）

顺风车（业务发展）

巴士业务（业务发展到一定体量）

可以看到，每一个阶段的业务基本都在之前的基础上进行迭代，这样的设计过程也有助于开发底层的业务架构设计，大大提升后续业务迭代的效率。

同时高质量的领域模型本身一定会具备三个特点，帮助团队建立共识，联接业务产生洞察，完善产品持续演进。

针对业务，如何产生洞察，不光是靠业务人员的经验和直觉，如何分解业务本身以及描述总结抽象的能力也至关重要，这一块我会在之后的章节中来和大家分享。

如何运用领域模型？

在运用领域模型前，我们首先要知道它并不只是我们业务分析的产物，而是贯穿全流程的。当业务在发展前进的时候，当下的领域模型不再满足业务时，一定要及时跟进修正。

没有完美的领域模型，一定会有潜在的场景或者需求会打破这种完美。所以在运用的过程中，一定要接受这种缺陷并对其保持演进。

第二点，针对领域模型中的概念或者模块，团队内部一定要保持统一认知，避免对于同一对象产生理解上的分歧。

同时保持对业务的深层次认知，不要急于将单一的对象作为一个概念，我们举一个小小的例子让大家感受一下。

那么怎样才是更好的做法呢，看下图：

这里也稍微说一下类图的使用方法，对于业务分析，我们可以基于开发规范下的类图进行简化，具体的规则和使用方法以后有空我们再来详细说。如下图：

这次主要还是以概念性知识点为主，下一讲我会把关于如何产出高质量领域模型的过程以及一些实践分享给大家。

我是红尘，我们下期见！