领域模型驱动设计(ddd)之模型提炼

author author     2023-03-31     630

关键词:

参考技术A     当Java世界提供的可选择性框架平台越来越多时 我们可能被平台架构所深深困扰 而无暇顾及软件的真正核心 业务建模 其实 业务领域建模同样是一个比平台架构更复杂 更需要学习的新的领域

  相反 在实践中 我们技术人员在经过冗长的平台架构学习和实践后 就匆忙开始项目开发 这时是什么指导他们进行软件业务实现呢?大部分可能是依赖数据库建模 甚至是复杂冗长的数据库存储过程设计 这些已经开始走向面向对象分析设计的反方向 走上了一条错误的软件开发方向 最终开发出缓慢的 经常当机的Java企业系统

  如果你没有恰当的OO设计思想 Java就会用性能惩罚你 这可能是Java世界的一个潜规则

  那么 一个正确的OOA/OOD/OOP步骤是什么呢?目前围绕模型驱动设计(MDD)的设计思想成为主流思想 MDA更是在MDD基础上提升和升华 下面让我们首先了解 如何使用领域驱动设计思想来分析设计一个软件系统

  当我们不再对一个新系统进行数据库提炼时 取而代之的时面向对象的模型提炼 我们必须大刀阔斧地对业务领域进行细分 将一个复杂的业务领域划分为多个小的子领域 同时还必须分清重点和次要部分 抓住核心领域概念 实现重点突破

   核心领域模型

  精简模型 找出核心领域 将业务需求中最有价值的概念体现出来 让核心变精要 这实际就是一个使复杂问题变简单的过程 也是对我们软件设计人员真正能力的考验

  核心领域模型不是轻易能够发现 特别是他处于一个纷乱复杂的众多领域模型结构中时 核心模型通常是我们某个子领域关注的重点 例如订单模型是订单管理领域的核心 消息模型是论坛或消息领域系统的核心

  目前 分析领域有很多模式来帮助我们来提炼核心模型 例如四色原型 Martin Fowler 的分析模式等 例如MF的 分析模式 (Analysis Patterns)中的记帐模型就是不仅仅用来记录账目数值 而且可以记录和控制账目的每一次修改 而四色原型则是一种高于分析模式的一种原型基本模式 下面是本人根据四色原型提炼的核心领域模型概念

  一般情况下 在企业应用中 核心模型总是在其周围围绕一些所谓的 卫星 这实际上也是来自四色原型的一个推论 核心模型和其 卫星 的类图如下

  

  根据Eric Evans在其 领域驱动设计 一书中定义 领域模型划分为实体和值对象两种 实体模型是指业务领域中具有独立属性的对象 而值对象则可能是一种Description或状态或规则 只要有实体对象 就可能存在实体的状态 状态跟踪有时成为一个业务领域使用计算机软件的首要跟踪 但是 数据库不是对象状态的唯一表达方式 只是一种存储方式(见状态对象 数据库的替代者)

  图中 实体核心对象大部分可能有一种类型 例如核心模型是产品 那么存在产品目录 核心模型是消息 就存在消息类型 核心模型是信息 总存在信息类别 我们总是使用分类方式来管理业务领域的信息 有时 类别甚至复杂到树形结构

  核心实体模型有时会有一个 :N关联的子实体 一般可能表达实体的细节 例如 核心模型是订单 那么存在订单条目这样一个细节 一个订单中可能有多个订单条目 如果核心模型是信息 那么存在该信息的多个回复或评论 这样的关联一般存在多个业务领域中

   模型界面实现

  原来 我们以为分析设计阶段无需了解实现细节 分析人员只要闷头做分析UML图 而无需顾及如何具体实现 其实这是一个误区

  Eric Evans在其 领域驱动设计 一书中认为 分析人员负责从领域中收集基本概念 设计则必须指明一组适应编程工具构造的组件 以及这些组件必须能够在目标环境中有效执行 模型驱动设计(Model Driven Design)抛弃了分裂分析模型与设计的做法 使用单一的模型来满足这两方面的要求 因此 对于核心模型必须掌握了解其实现细节

  从另外一个方面来说 中国的客户总是从界面设计来表达他们的意图(如果中国客户能够使用Use Case等UML图来表达他们概念真是不可想象) 例如客户会说 我希望有一个界面让我将订单数据输入 然后能够查询符合查询条件的订单 因此 我们的核心模型至少能够顺利地映射到界面实现 相反 这个客户有这样订单界面要求 但是你没有提供一个与之适应的核心实体模型 界面实现将变得复杂 甚至走很多弯路 诞生不少DTO垃圾对象

  以JdonFramework框架实现为例子 框架提供了围绕核心模型的新增删除修改查询(CRUD)功能以及批量功能的快速实现 尤其CRUD功能实现前提是必须提炼出核心模型 从而其界面设计流程就能通过配置立即实现 这样一步到位实现领域模型到界面的过渡 可以将我们设计核心模型和客户要求的界面需求能够做到完整的统一

  开源JdonFramework下载包中message案例实际就是上述核心模型图的一种实现项目 更复杂的项目可以认为是核心模型的重叠和反复使用(从原理上讲 核心模型是四色原型的体现 而四色原型被认为是大部分企业系统的基本组成元素 见[book][UML][Peter Coad]Java Modeling in Color with UML)

   核心模型的选择

  实际项目中 会存在多个核心模型的重叠和覆盖使用 主要取决于你的领域关注重点

  例如当客户和我们说要做一个旅游网站时 我们必须充分了解需求 它的软件系统重点是哪些功能 如果当他首先说 我需要一个酒店设备的查询系统 因为他的客户对酒店设备非常关注 那么我们可能认为酒店设备是这个领域模型的核心 酒店设备 如果他又进行描述 我需要一个界面 客户在输入酒店资料时 选择多个酒店设备 那么在这样一个关注领域 核心模型实际是酒店 而酒店设备可能成为酒店的一个特征实体属性 甚至是值对象了

  以进销存系统为例子 在采购系统中 采购单是一个核心实体模型 而原材料是一种辅助实体模型 在库存系统中 入出库单是一个核心实体模型 原材料或成品代表的是一个库存物品概念模型 当需要库存报表查询输出 可以立即计算出来 或将结果缓存起来 缓存起来的结果其实是库存物品对象的状态 可以使用值对象来实现

   核心模型的精练

lishixinzhi/Article/program/Java/gj/201311/27660

我对领域驱动设计(ddd)的学习成果

领域驱动设计之领域模型2004年EricEvans发表Domain-DrivenDesign–TacklingComplexityintheHeartofSoftware(领域驱动设计),简称EvansDDD。领域驱动设计分为两个阶段:1.以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交... 查看详情

ddd学习笔录——提炼问题域之有效提炼知识的模型

方式六:延迟对模型中概念的命名对领域建模时命名很重要。因为在不断的知识提炼过程中经常会发现已经被命名的概念与你最初理解的有出入,这时你当初的命名就会变成一个问题。其问题在于 最初选作名称的这个词所带... 查看详情

ddd领域驱动设计-ddd概览

参考技术A#DDD概览##启迪领域可以理解为业务,领域专家就是对业务很了解的人。限界上下文也就是微服务的边界,也可以理解为微服务,一个限界上下文=一个微服务。个人理解领域驱动设计就是微服务驱动设计,从战略上先进... 查看详情

什么是ddd(领域驱动设计)?

领域驱动设计的基本概念领域驱动设计作为一个针对大型复杂业务系统的领域建模方法体系(不仅限于面向对象的领域建模),它改变了传统软件开发工程师针对数据库建模的方式,通过面向领域的思维方式,... 查看详情

ddd(领域驱动设计)

模型驱动设计(DomainDrivenDesign)模型关系图(Model-DrivenDesign)领域驱动设计中的模型关系图如下:层结构(LayeredArchitecture)UserInterface负责向用户展现信息,并且会解析用户行为,即常说的展现层。ApplicationLayer应用层没有任何的业务逻辑... 查看详情

领域驱动设计实战-ddd

领域驱动设计实战领域驱动(DDD,DomainDrivenDesign)为软件设计提供了一套完整的理论指导和落地实践,通过战略设计和战术设计,将技术实现与业务逻辑分离,来应对复杂的软件系统。本系列文章准备以实战的角度来介绍DDD,首... 查看详情

学习:ddd领域驱动设计

DDD:Domain-drivenDesign(领域-驱动->设计)->领域驱动领域模型设计->领域模型驱动代码实现 摘自网络(汤雪华的博客)《概念总结》领域就是问题域,有边界,领域中有很多问题;任何一个系统要解决的那个大问题都对应... 查看详情

ddd领域驱动设计:贫血模型和充血模型详解(代码片段)

文章目录前言一、贫血模型1.介绍2.优点3.缺点4.代码样例二、充血模型1.介绍2.优点3.缺点4.代码样例三、对比分析1.为什么基于贫血模型的传统开发模式如此受欢迎?2.什么项目应该考虑使用基于充血模型的DDD开发模式?结... 查看详情

ddd领域驱动设计基本理论知识总结

 原文:DDD领域驱动设计基本理论知识总结 领域驱动设计之领域模型加一个导航,关于如何设计聚合的详细思考,见这篇文章。2004年EricEvans发表Domain-DrivenDesign–TacklingComplexityintheHeartofSoftware(领域驱动设计),简称EvansDDD... 查看详情

浅谈我对ddd领域驱动设计的理解

目录从遇到问题开始DDD切入点1-理解概念什么是领域(Domain)?什么是设计(Design)?什么是驱动(Driven)?概念总结:DDD切入点2-理解领域、拆分领域、细化领域理解领域知识是基础拆分领域细化子域DDD切入点3-领域模型设计领... 查看详情

ddd领域驱动设计-设计文档模板

...板:系统背景和定位需求描述系统用例图关键业务流程图领域语言整理,主要是整理领域中的各种术语的定义,名词解释领域划分(分析出子域、核心域、支撑域)每个子域的领域模型设计(实体、值对象、聚合、领域事件,需... 查看详情

ddd的理解

DDD领域驱动设计:是一种设计思想,应用到IT技术领域,主要是指导微服务设计和划分的思想.DDD强调通过领域驱动设计方法定义领域模型,确定业务和应用的边界,保证业务模型和代码模型的一致性.DDD通过建立领域模型 --> 划分领... 查看详情

ddd学习笔录——提炼问题域之知识提炼与协作的基本原则

...题专家进行建模时,每个人都应该有意识地始终应用富含领域专有术语的通用语言。这一语言必须现实制作,并在描述领域模型和问题域时使用。该语言还应该用于模型的代码实现,使用用作类名、属性和方法名称相同的术语和... 查看详情

DDD - 持久性模型和领域模型

】DDD-持久性模型和领域模型【英文标题】:DDD-PersistenceModelandDomainModel【发布时间】:2012-12-1102:04:19【问题描述】:我正在尝试学习领域驱动设计(DDD),我想我已经掌握了基本概念。但是有些事情让我很困惑。在DDD中,持久性模... 查看详情

谈谈ddd(领域驱动设计)(代码片段)

...组织了小红花的新一期分享快速搞定数字化项目——采用领域驱动设计(DDD)建设一个电商平台,听完池总的这个分享之后,我终于是把这两年重新热起来DDD(以下称为现代DDD)和我十几年前熟悉的DDD(以下称为... 查看详情

领域驱动设计

1.什么是领域驱动设计(DDD:DomainDrivenDesign)    领域驱动设计(DDD)是一种基于模型驱动的软件设计方式。它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题。领域... 查看详情

领域驱动设计——一种将概念模型化的方式

...main-DrivenDesign:TacklingComplexityintheHeartofSoftware》(中文名:《领域驱动设计:软件核心复杂性应对之道》),在这本书中作者提出了领域驱动设计(DDD)的概念,到现在已经10多年的时间了。1. 查看详情

领域驱动设计——一种将概念模型化的方式

...main-DrivenDesign:TacklingComplexityintheHeartofSoftware》(中文名:《领域驱动设计:软件核心复杂性应对之道》),在这本书中作者提出了领域驱动设计(DDD)的概念,到现在已经10多年的时间了。1. 查看详情