浅谈领域模型

浅谈领域模型

閱讀本文約花費: 10 (分鐘)

|01 领域模型是什么

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

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

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

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

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

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

|02 领取模型怎么设计

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

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

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

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

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

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

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

模型概念

模型属性和属性值

模型之间的关系

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

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

|03 领域模型的价值

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

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

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

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

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

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

统一语言:沟通更加顺畅,分歧易于解决;

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

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

|04 数字化转型

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

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

Rate this post

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注