领域建模的一点思考

最近听了一个相关的讲座，有一点感触和思考记录下。且不谈各种专业的概念，不谈各种复杂的流程图，我理解领域建模更多地是一种指导思想，或者说一种做事方式。

谈谈我理解领域建模的两个核心点：

一、何为“领域建模”

    建模绝对不是一个新概念，传统软件设计，我们也会建模，常见地，设计db表结构或者ER图就是建模的一种（存储建模）。
而领域建模这几年之所以很火的原因是：随着业务系统复杂性的提高，需要更加科学和系统的建模方法，来增强对事物本质的理解以及帮助使用更加合理的系统来实现和支撑业务。

    领域建模和存储建模（ER图）主要有两点区别：1、层次不一样（如下图所示） 2、关注重点不一样。存储建模更多地关注了技术实现，领域建模更加强调从业务视角去理解。领域建模的产出一定是产品、技术、运营都能够理解的业务概念，不带有任何技术术语，是对业务的统一认知。

    领域建模的核心是如何界定领域（domain）和子域（subDomain）。这个依赖于对业务的理解能力和对客观世界的理解流程。讨论及确定领域的过程，非常重要，最好可由产品、运营、技术等各方一起头脑风暴，经过多轮讨论确定。确认后，各方可从领域建模的产出对业务达成一致的认识。——这块是我们以前很可能忽视的一个方面。

    基于业务场景确认好的领域（domain），从长远来看，是公司的一个“资产”，可以重复并且长期使用。反之，如果领域没有划分清楚，特别是一些子域交织不清，长期来看，必然需要重构和优化，这对公司来说，是一个“负债”。

 

二、统一语言

    领域建模的产出不是摆设，而是各方后续做事的依据。比如，产品运营同学，需要根据这个来考虑业务流程；技术同学需要根据这个来进行代码开发（甚至是类名、实体名）也要保持一致。这样做最大的好处就是：表里如一。即各方对于业务的理解并没有任何不一致，不需要任何“转换”或者“翻译”。

 

三、小结

就像“云计算”一样，炒热各种概念其实没有啥意义。领域建模于我们工作而言，我理解更多地是一种指导思想。当然，在实际工作中，需要把这种思想或者思维方式融入到实际的工作中，这样才有意义。至于领域建模如何应用到实践，这个每个人也许有不同的做法，也需要个人去理解。