您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
浅谈领域模型
 
作者:晓阳的数据小站
  2406  次浏览      14
 2020-10-9 
 
编辑推荐:
本文主要讲解了 领域模型是什么、 领取模型怎么设计、 领域模型的价值、数字化转型等相关内容。
本文来自于晓阳的数据小站,由火龙果软件Anna编辑、推荐。

|01 领域模型是什么

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

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

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

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

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

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

|02 领取模型怎么设计

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

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

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

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

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

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

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

模型概念

模型属性和属性值

模型之间的关系

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

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

|03 领域模型的价值

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

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

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

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

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

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

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

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

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

|04 数字化转型

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

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

   
2406 次浏览       14
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
iPerson的过程观:要 过程 or 结果
“以人为本”的工程哲学
企业架构、TOGAF与ArchiMate概览
UML 图解:顺序图( sequence diagram )
UML 图解:对象图( class diagram )
最新课程
基于UML和EA进行系统分析设计
UML+EA+面向对象分析设计
基于SysML和EA进行系统设计与建模
UML + 嵌入式系统分析设计
领域驱动的建模与设计
更多...   
成功案例
某电信运营供应商 应用UML进行面向对象分析
烽火通信 UML进行面向对象的分析设计
西门子 UML与嵌入式软件分析设计
航天科工某子公司 从系统到软件的分析、设计
深圳某汽车企业 模型驱动的分析设计
更多...