关于需求建模域建模: 区分问题域和问题解决域（转移）

关于领域建模的讨论（1）:

将问题域与问题解决域分开

域和域模型

俗话说，每个人的心中都有一个Hamlet，每个人的心中都有一个领域模型定义.

常见的是:

声明1: 我了解的领域是业务工作的分类. 分类的方式是业务工作具有相关知识. 这些必需的知识构成一个领域. 这些知识是业务工作的背景. 现场分析可以帮助我们挖掘，分析和理解业务工作的本质. 换句话说，领域服务于需求分析工作，其目的是挖掘，分析和理解业务工作的本质.

声明2: 域模型是现实世界中概念类和对象的直观表示.

声明3: 在企业应用程序体系结构模型中明确提出了三种域逻辑组织模式: 事务脚本，域模型和表模块. 域模型将行为和数据作为域逻辑的核心.

从以上可以看出，有三种方式可以表示您可以在不同的上下文中看到不同的视图，甚至不能看到相同的表达式对象. 企业应用程序体系结构模型中的域模型是从设计到实现层的概念，参数1，参数2域是业务级别和分析阶段的概念. 因此，本文专门从业务角度引用[域模型]模型，参考定义如下:

•域: 与系统有关，是系统要解决的实际问题.

•领域模型是领域中概念类或现实世界（百度）中对象的直观表示.

•领域模型是针对特定问题的所有相关方面的抽象模型（维基百科）

1.jpg

想想如何对上图中的元素建模？

域建模的好处

域建模有什么好处？

统一语言和对不同角色的统一认知

2.jpg

如上图所示，在客户的需求发展之后，它已经变得面目全非，每个加工和制造环节都认为这是“正确的做事”. 您是否见过如此生动的情况屡屡发生:

产品经理宣讲prd. 产品经理需要将名词分别翻译给业务方和开发人员，一种商务语言和一种技术语言.

为了争辩一个名词的定义，好几个建筑师在小小的黑屋子里争论了很长时间. 例如，什么是付款？百度百科的解释是: 由社会经济活动引起的货币债权转移过程. 包括: 交易，清算，结算.

然后可以根据其含义比较以下情况是否属于支付类别.

用户A向B汇款.

用户通过XX网站归还.

用户在天猫上买了东西，然后用花北买了东西.

可以看出，明确的统一语言非常重要，以便利益相关者理解讨论是一回事.

描述业务的本质并抓住主要思想

例如，在支付宝源园的开发中，我们使用了红包，实时折扣和商户优惠券等产品. 这是烟囱建筑发展的产物.

3.jpg

该行业还拥有其他类似的证券，如下所示:

4.jpg

让我们谈谈这三种产品:

1. 对于商家或机构而言，是否可以调用这些产品（包括费用）可以出售给商家.

2. 对于用户，他们是否需要了解这三件事是不同的？这些观念对于营销，交易和品牌有什么好处？

3. 对于支付宝平台，他们的管理模式有什么区别？

4. 对于技术团队，他们可以抽象吗？

后来，我们在产品上形成了以下定义:

优惠券定义:

是票据，作为发行者和票据所有者之间的凭证，具有一定的价值和法律效力.

相关利益相关者:

优惠券的发行人[提供优惠]

优惠券的所有者[享受权益]

凭证发行工具[是一种用于向债券发行所有者发行凭证的工具]

优惠券表格:

按媒介分类: 纸质优惠券，电子优惠券

按用途分类: 入场券，礼品券，送货券，凭证，红包，折扣卡，全价优惠卡等.

优惠券可以用作基本产品，商业表格可以包装为折扣卡，全额折扣卡和其他用户认可的[产品]或[营销工具].

域模型= ER？

域模型是ER模型吗？答案是否定的. 领域模型是特定业务领域中业务实体之间关系的自然出现，而ER是设计阶段实现关系的产物.

如下图所示，特定业务领域中有两类自然人，一种是客户领域建模，另一种是员工.

5.png

但是就其实现而言，设计有多种形式.

6.png

7.png

8.png

域建模= DDD吗？

在提到领域建模时就提到了DDD，这是每个人的自然反应. 因为DDD（著名的建模专家Eric Evans在2004年出版了他最有影响力的著名著作: “域驱动设计–软件中心的复杂处理”）是众所周知的. 我的观点是，域模型的生成是分析阶段的产物. 分析是在不创建内容的情况下挖掘需求和需求背后的相关内容. 顾名思义领域建模，DDD是模型驱动的设计，这是一种从需求到设计阶段的方法.

领域建模涉及哪些概念？

域（域）: 要讨论的问题的范围，称为域或问题域.

Subdomain: 通过在不同纬度上划分域而具有相对凝聚力的单位. 例如，电子商务业务涉及订单，库存和营销子域.

上下文（context）: 它是由讨论领域中的特定人群形成的上下文. 在这里，我们应该强调一个概念，即特定的人群不是由团队或项目划分的群体，而是由知识划分的群体. 换句话说，上下文不是通用的，而是存在于一群人中，并且大多数上下文以隐性知识（默认知识）的形式存在.

无所不在的语言: 域模型可以成为每个人交流的通用语言的核心，同时紧密地联系团队交流和软件实现. 在整个团队的工作中，这种通用语言是UBIQUITOUS语言（通用语言）.

实体: 实体是一个域的概念，需要在该域中进行唯一标识. 因为我们有时需要区分哪个实体. 有两个实体，如果唯一标识符不同，那么即使该实体的所有其他属性都相同，我们也认为它们是两个不同的实体. 因为实体具有生命周期，所以实体在创建之后可能会保留在中，然后有时会再次将其取出. 因此，如果我们不为实体定义唯一可区分的标识符，那么我们就无法区分该实体和哪个实体.

值对象（值对象）: 值对象没有唯一的标识符，这是它与实体之间最大的区别. 联邦调查局在一部电影中发现，通过一次隐私调查，发现男主人和女主人在大学期间有相同的收信地址，并判断他们已经住在一起. 这里的地址可以用作值对象，其所有属性都可以确定其身份，而不必通过ID进行区分.

触发事件（事件）: 企业级应用程序事件可以大致分为三类: 系统事件，应用程序事件和域事件. 域事件的触发点在域模型中，因此可以获取其名称. 通过使用域事件，我们可以通过事件分派机制实现域模型对象状态的异步更新，对外部系统接口的委派调用以及系统集成. 在系统分析阶段，我的观点是不区分事件类型.

想想Event和MI在颜色建模中的区别和联系吗？

电信信息体系结构中有大量事件，如下图所示.

9.jpg

观点: 建议不要在分析阶段区分实体和价值对象

不建议在分析阶段区分实体和值对象. 例如，“客户”和“地址”之间的关系相同. 在随后的细化过程中，理所当然地很清楚. 例如，地址可以重复使用，并且不是唯一的.

观点: 可以在域模型中添加业务规则作为补充

可以将业务规则作为补充添加到域模型中. 例如，下图显示了对交货单和订单项目之间关系的限制: 仅当所有订单项目都已交付后，订单才能成功关闭.

10.jpg

让我们看一下DDD的内容，它是领域建模（应在分析阶段识别出来）.

11.jpg

如上图所示，在分析阶段最多可以使用实体和值对象. 再次证明DDD是一种注重设计的工具.

基于领域，领域语言等的概念，不难理解同一名词在不同领域中的含义是不同的. 即使是同一媒介，其内涵和外延也是不同的. 我们可以将该域表示为问题域.

例如，电子商务网站上有优惠券，包括天猫购物优惠券，商店优惠券，商品优惠券等. 下面的屏幕截图是淘宝优惠券的屏幕截图.

12.jpg

还有一个专门用于优惠券导航的网站: 优惠券母亲.

13.jpg

这两个网站管理的优惠券属于同一类. 他们的模特都一样吗？这两个网站管理凭证，但是业务实体[凭证]不同，因为它们要解决的问题域不同. 优惠券母亲是一个流量门户，专注于使用和跳跃；淘宝优惠券关注的是[下订单时扣除订单金额]的用法，包括使用优惠券的用户对商店的粘性，二次消费等. 经营实体的商业行为和状态也各不相同.

问题领域vs解决问题领域

14.jpg

最后，归纳起来，问题域和问题解决域是两类，分别属于分析，设计和实施阶段. 不同阶段使用的工具和目标也不同，如下图所示:

15.jpg

在分析阶段的域模型中，我认为域实体和关系的主要描述可以帮助解释域术语（可以以业务词典的形式）和约束（业务规则），而业务实体（域实体）仅描述主要功能.

最后，我们推荐微信:

16.jpg

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-229246-1.html