DDD的优势(3)

简介: DDD的优势(3)

7.6 领域建模方法

7.6.1 用例分析法

1.方法介绍

用例分析法是进行领域建模中最简单可行的方式,其步骤如下。

(1)获取用例描述

既然领域模型指的是问题域模型,那么建模也一定要从问题域入手。那么问题域的知识如何表现出来呢?一种最常见的方式是通过用例,也可以通过场景(Scenario)来分析,总之就是一段格式化的需求文字描述。

(2)寻找概念类

寻找概念类就是对获取的用例描述进行语言分析,识别名词和名词短语,将其作为候选的概念类。当然,需求描述中的名词不可能完全等价于概念类,自然语言中的同义词和多义词都需要在此处进行区分。还有很多名词可能只是概念类的属性,不过没关系,在这一步骤中可以都提取出来,在第4步中再区分出概念类和属性。

(3)添加关联

关联意味着两个模型之间存在语义联系,在用例中的表现通常为两个名词被动词连接起来,如图7-12所示。

在添加关联关系时要注意以下几点。

  • 并非所有动词关联的概念类都需要作为关联存在,更重要的是我们需要判断两个概念类的关系是否需要被记住。
  • 应该尽量避免加入大量关联。
  • 关联不代表数据流,也不代表系统调用关系。


image.png


(4)添加属性

我们需要区分概念类和属性(当然名词列表也会有无用的词语)。例如,对于上文抽取到的名词列表,“品名”是“商品”的属性,“iTouch”为无用的词语。

如何判断一个名词是否是属性?可以用下面两种方式。

  • 能完全通过基本数据类型(数字、文本、日期)表达的大多是属性。
  • 如果一个名词只关联一个概念类,并且其自身没有属性,那么它就是另一个概念类的属性。
(5)模型精化

模型精化是可选的步骤,有时我们希望在领域模型中表达更多的信息,这时会利用一些新的手段来表达领域模型,包括泛化、组合和子域划分等。领域模型可以使用UML的泛化和组合表达模型间的关系,表达的是概念类的“is-a”和“has-a”的关系。子领域划分是常见的拆解领域的方式,通常来说,我们会将更内聚的一组模型划分为一个子领域,形成更高一层的抽象,有利于系统的表达和分工。

2.案例介绍

下面举例说明,内容来自论文“Object-Oriented Analysis from Textual Specifications”,文中讲述了如何通过自然语言分析来做面向对象分析。

用例描述如下所示:

Vendors may be sales employees or companies. Sales employees receive a basic wage and a commission, whereas companies only receive a commission. Each order corresponds to one vendor only, and each vendor has made at least one order, which is identified by an order number. One basic wage may be paid to several sales employees. The same commission may be paid to several sales employees and companies

接下来,我们按照用例分析法的步骤来建模。

(1)寻找概念类

首把所有名词标记出来,作为概念类的候选类:vendors, sales employees, companies, basic wage, commission, order, order number。

(2)添加关联

如图7-13所示,接下来为名词添加关联,连接这些名词的动词会出现在关联的线上。注意,根据上面的用例,我们还不清楚给供应商(Vendor)支付佣金(Commission)的主体是谁,但这并不妨碍在本阶段的建模。


image.png


(3)添加属性

最后,为这些候选的概念类选择属性。在本例中,如果一个概念类只处于一个被动的关联关系中(如Basic Wage, Commission, OrderNumber),那么它需要作为关联类的属性,如图7-14所示。



image.png

相关文章
|
8月前
|
领域建模
架构设计 DDD领域建模 核心概念
【1月更文挑战第6天】架构设计 DDD领域建模 核心概念
|
缓存 前端开发 中间件
DDD 领域驱动设计落地实践系列:工程结构分层设计
前面几篇文章中,笔者给大家阐述了 DDD 领域驱动设计的三大过程,重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论,但是还没有涉及到工程层面的落地。实际上所有的这些架构理论到最后都是为了使得我们代码结构更加清晰,从而开发出 bug 少、扩展性强、逻辑清楚的应用。因此本文就是为了解决 DDD 领域驱动落地实践最后一公里问题,将我们分析出来的领域模型通过与工程结构的映射实现真正的落地。
DDD 领域驱动设计落地实践系列:工程结构分层设计
|
存储 自然语言处理 前端开发
领域驱动设计(DDD)-基础思想
一、序言     领域驱动设计是一种解决业务复杂性的设计思想,不是一种标准规则的解决方法。在领域驱动设计理念上,各路大侠的观点也是各有不同,能力有限、欢迎留言讨论。 二、领域驱动设计 DDD是什么 wiki释义:     领域驱动设计(英语:Domain-driven design,缩写 DDD)是一种通过将实现连接到持续进化的模型[1]来满足复杂
7564 0
|
3月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
5月前
|
存储 消息中间件 JSON
|
8月前
|
数据库
DDD架构浅谈
DDD架构浅谈
189 4
|
消息中间件 JavaScript 小程序
领域驱动设计(DDD)的几种典型架构介绍
领域驱动设计(DDD)的几种典型架构介绍
|
设计模式 缓存 Java
DDD之代码架构
这是一篇迟到的文章。这其实是我写DDD的第四篇文章。去年11月份左右我在个人网站上写了三篇关于DDD的文章,都是比较偏战略部分的。那个时候我还在一个正在使用DDD的项目上,也是我第一次真正开始深入使用DDD。
628 1
|
设计模式 JSON 缓存
|
Java uml
DDD的优势(4)
DDD的优势(4)
271 0
DDD的优势(4)