推广策略及推广方式,seo快速排名上首页,酒店网站建设报价单,wordpress 添加证书|0x00 领域模型是什么
领域模型是什么#xff1f;一句话#xff1a;“经济基础决定上层建筑”中的“经济基础”#xff0c;是帮助理解复杂业务领域问题的基石。
有人说#xff1a;“领域模型是一个商业概念#xff0c;同行业的企业#xff0c;一定有内在的共性#xf…|0x00 领域模型是什么
领域模型是什么一句话“经济基础决定上层建筑”中的“经济基础”是帮助理解复杂业务领域问题的基石。
有人说“领域模型是一个商业概念同行业的企业一定有内在的共性是帮助系统分析人员认识现实业务的工具。”领域即边界的意思有了清晰的边界协作才有了利益的基础模型即知识体系深入理解了业务知识开发才不会走过多的弯路。一般意义上的领域模型是面向软件工程领域的而现实意义的领域模型则包含了商业模式等广义上的概念。
很多人一上来理解领域驱动设计DDD基本都是一头雾水因为模型设计的初衷并不是围绕性能、架构、分层等软件概念展开的而是从边界、内聚等抽象概念开始讲起。理解领域模型并不是通过技术的思维来学习而是通过不断地实践过程来训练自我的思维意识进而彻底形成结构化与面向对象的思维方法论。
领域模型并不能直接带来收益只是辅助我们去理解正在做的事情。
引用百度的说法“领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身发掘重要的业务领域概念并建立业务领域概念之间的关系。”总结一下就是“准确描述问题清晰描述方案”。 如果说软件开发的本质是从“问题空间”到“解决方案空间”的转化那么“领域模型”就是“解决方案空间”的架构通过抽象的模型为系统带来统一的认知。
|0x01 领取模型怎么设计
设计领域模型之前首先要确定“问题空间”即对需求进行分析和拆解。值得注意的是领域模型通常是针对比较大的系统设计而言如果是日常功能迭代中的小需求那么只需要根据已经设计好的模型原则来做对应的开发即可。
需求分析阶段要做的就是确定系统要实现的核心功能是什么用UML来表达设计意图是非常好的工具。UML通过动静结合的图示便可以比较清楚的阐述系统的核心职责与过程。
类图静态展示了模型中存在的类、类的内部结构以及它们与其他类的关系等状态机动态对一个单独对象的行为建模指明对象在它的整个生命周期里响应不同事件时执行相关事件的顺序时序图动态描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
接下来就是业务建模阶段了。在大多数讲领域驱动的书籍里都会将领域划分为领域子域和限界上下文。领域是一个模型所包含的全部事情子域是指模型的某个细分部分根据重要性可以划分为核心、支撑和通用限界上下文是一个业务边界边界内的术语都有其特定的涵义例如银行系统和电商系统中顾客就不是同一个意思。这种划分方式通常是非常灵活的跟设计者的个人经验有比较大的关系。 将系统拆分完成后就需要确定子域/上下文之间的关系以及相互之间的信息如何进行流转例如
模型概念模型属性和属性值模型之间的关系 最后就是通过某些具体的方法论分析具体的模型设计了。设计的方法论也有很多种例如在用例分析方法中就是尽可能的收集用例素材通过例图以图形化的方式将系统描述成用例、参与者用户及其之间的关系在DODAF中是采用标准方法表述“EA的数据和关系类型”的指引解决复杂系统结构化问题的指引。在四色建模法中用蓝色表示命令用红色表示实体用绿色表示领域事件用黄色表示补充信息相关的实体便可以整理到同一个领域中。建模方式有很多种不论是已有的方法论或者是通过日常的业务经验积累来设计只要能将模型描述清楚都是可用的。
做个总结就是抛开技术视角用纯业务的视角来建立模型。但确定的一点是领域模型的优先级要高于软件解决方案先有领域建模的整体框架然后才是将模型映射到软件架构之中。 |0x02 领域模型的价值
建模是一个团队性的复杂工作经过长时间的摸索有几个特点还是可以总结出来
建模的时候不要立刻开始设计具体的模型而是先对业务进行分析和拆解很多时候业务人员也不一定非常熟悉业务前期调研的过程是必不可少的。为了避免产生歧义在建模的过程中最好使用统一的术语与工具例如UML。学会适应变化模型本身是会发生变化的变化的频率取决于业务发展的速度当下的形态都是某种意义上的中间态。
一个好的软件系统需要同时在满足业务需求和系统底层架构之前做权衡产品运营往往不具备技术背景因此在“做不做”与“怎样做”之间往往会爆发激烈的冲突。更多的时候是对同样的概念双方都有不同的理解这种GAP不一定是“大到天边”的那种差异而是针对某些具体的细节发生了误解但这种细节往往非常致命。这时候通过模型来反应实际的业务情况相当于说明书的作用来与需求方沟通就会有效的多。
因而从全局的角度看领域模型会带来如下的价值
统一语言沟通更加顺畅分歧易于解决知识沉淀通过对业务领域的熟悉过程能够以模型的方式沉淀下来对于自己提升与团队传承均有帮助保持清晰在需求沟通时能够快速明确哪些需求是合理的哪些是违反业务规则的可以让业务跑的更快的同时保持系统结构的清晰。
|0xFF 数字化转型
看完前面的内容大多数人会有一种疑问即领域模型适用在哪里大多数的互联网场景下用了领域模型反而会让业务更复杂。其实自Eric Evans在2003年出版《领域驱动设计软件核心复杂性应对之道》之后领域模型的概念才深入人心那会互联网发展的并不充分。而随着近几年越来越多的企业意识到数字化的重要性如何用数据去驱动特定行业的发展比如制造业慢慢的成为了一种潮流。在这种潮流里革新传统行业的大概率不是从传统行业走出来的人而是依赖于掌握了数字化技术的人技术人怎样快速去了解和深入一个陌生的行业呢领域模型自然就派上了用场。
例如在信息时代常见的生产力工具ERP和MES能够解决信息化的很多问题但是对于生产流转的过程掌握就不那么适用了尤其是5G之后很多设备也具备了数字化的特征。用以“数据流”为主要特点的新管理系统去适应和替代原有的生产系统就显得很有必要。但过去的“数据流”依赖于Hadoop体系及维度模型这套组织方式套用到过去的管理系统中会产生很多的不适应性因而通过领域模型的方式去抹平技术上的种种差异为传统VS互联网行业的人达成共识共同推动系统改造就创造了基础。
