- 浏览: 592245 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (300)
- Web前端 (27)
- Java疑难 (60)
- 面试 (59)
- 汇编语言 (1)
- 计算机组成原理 (2)
- 操作系统 (3)
- 计算机网络 (6)
- C/C++疑难 (9)
- SSH (2)
- Web开发 (15)
- 故障 (3)
- 软件开发 (16)
- Portal开发 (1)
- 后台开发 (6)
- 数据库 (35)
- 设计模式 (4)
- 数据结构与算法 (4)
- Linux (3)
- 项目管理 (10)
- 多线程 (12)
- 嵌入式 (9)
- 网络编程 (4)
- 架构设计 (20)
- 软件工具技巧 (7)
- 并行并发 (4)
- 窗口编程 (7)
- 串口编程 (0)
- Flex (2)
- 协议 (1)
- 通讯方式 (4)
- 性能分析优化 (5)
- 测试相关 (4)
- 海量数据处理 (2)
- JAVA核心技术 (10)
- SOA (3)
- 攻略规划 (1)
- 爬虫/搜索 (2)
- 正则表达式 (1)
- A Comparison Of NoSQL Database Management Systems And Models (1)
最新评论
-
charles751:
分析的很好!但有一点:只要同步组合操作就可以了,不一定非要sy ...
Vector 是线程安全的? -
S346618898:
core Java中有一段:Vector类对自己的所有可修改方 ...
Vector 是线程安全的? -
code_cj:
基本上明白了.但执行顺是否应该是/etc/profile -& ...
profile bashrc bash_profile之间的区别和联系 -
xd2008ck:
各自有各自的场景吧楼主不要太激进了
Vector 是线程安全的? -
zwt2001267:
写的不错,赞一个
Vector 是线程安全的?
摘自http://www.jdon.com/42751
最近又重温了领域驱动设计的原著,有了一些新的理解。现在我觉得我能更好地理解jdon007之前说的下面这段话了。
“用
户需求”不能等同于“用户”,捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。
《老子》书中有个观点:有之以为利,无之以为用。在这里,有之利,即建立领域模型;无之用,即包容用户需求。举些例子,一个杯子要装满一杯水,我们在制作
杯子时,制作的是空杯子,即要把水倒出来,之后才能装下水;再比如,一座房子要住人,我们在建造房子时,建造的房子是空的,唯有空的才能容纳人的居住。因
此,建立领域模型时也要将用户置于模型之外,这样才能包容用户的需求。
所以,我的理解是:我们设计领域模型时不能以用户为中心为出发点去思考问题,不能老是想着用户会对系统做什么;而应该从一个客观的角度,根据用户需求挖掘出领域内的相关事物,思考这些事物的本质关联及其变化规律为出发点去思考问题。
下面以Eric Evans(DDD之父)在他的书中的一个货物运输系统为例子简单说明一下。
在经过一些用户需求讨论之后,在用户需求相对明朗之后,Eric这样描述领域模型:
1. 一个Cargo(货物)涉及多个Customer(客户,如托运人、收货人、付款人),每个Customer承担不同的角色;
2. Cargo的运送目标已指定,即Cargo有一个运送目标;
3. 由一系列满足Specification(规格)的Carrier Movement(运输动作)来完成运输目标;
从
上面的描述我们可以看出,他完全没有从用户的角度去描述领域模型,而是以领域内的相关事物为出发点,考虑这些事物的本质关联及其变化规律的。比如第1点,
如果是以用户为中心的话,就变成了:一个托运人可以托运货物,即具有托运货物的行为,一个收货人可以收货物,一个付款人需要付款;而他的描述中完全以货物
为中心,把客户看成是货物在某个场景中可能会涉及到的关联“事物”,如货物会涉及多个客户,货物有一个确定的目标,货物会经过一系列列的运输动作到达目的
地;其实,我觉得以用户为中心来思考领域模型的思维只是停留在需求的表面,而没有挖掘出真正的需求的本质;我们在做领域建模时需要努力挖掘用户需求的本
质,这样才能真正实现用户需求;
这让我想到了我之前思考图书借阅系统时的出发点也是错误的,因为我之前总是在以用户为中心思考问题。比如借书者借书,借书者还书,管理员对书本入库,等等;经过上面的分析后,我觉得我应该以书本为核心出发点思考领域模型。如:
1. 一本书在某个时刻最多只能被一个人借,或者没有被借走留在图书馆;
2. 书本在被归还时需要检查归还时间,如果有超期则需要做罚款处理;
3. 一本书有库存信息,如书本存放位置,库存数量;
4. ……
没有从用户的角度去描述领域模型,而是以领域内的相关事物为出发点。
看来认识识分析需求有两种线索,一个是以人为核心的需求分析;还有一个与人无关,事物领域自身的内在规律,或者称为“道”。
至于以哪个为主要为侧重点,还是要看人和事物在不同场景中扮演戏份的多少与否,比如在货运系统中,从这个名字我们也可以看出以货为主的一个运输系统,因此,人应该处于次要地位。
但是图书馆借书这个案例中,我个人认为好像不是以书为主的自主运动,而是以人为主,书为辅助的这样一个系统,如果以书为主,就发生“书被借”这样奇幻事情发生,呵呵。
人 != 用户
比如,人口档案管理系统,系统中应有记录人的信息或者说存在关于人的模型,但这个人的模型并不表示用户。
图书馆管理系统,用户群若是“读者”,那么应该将“读者”(用户)至于模型之外;如果用户群是图书馆管理员,那么“读者”(不再是用户,哪怕命名为用户),可以置于模型之内(比如要挖掘用户兴趣模型,发现什么的人群喜欢阅读什么样的书)。
物流系统,如果用户群是“顾客”,那么应该将“顾客”至于模型之外;如果用户群是“管理者”,那么可以将“顾客”(此时已不是系统的用户)放在模型之内。
将“用户”至于“模型”之外,用户群单一时,比较容易做到;若存在多种性质截然不同的用户群时,要注意到不同用户群将有不同的心智模型,尽管它们之间可能有交集。
但是,即便将不同性质的用户群的心智模型聚集在一起,也应遵循这个原则,并需要清醒地意识到视角潜在的变化(这可能被忽略或遗忘, 从而引起混淆)。
从整体上而言,“书”、“账号”、“书库”是模型(包括其结构/状态与功能/行为上的特征),可理解为系统的结构组成;“借阅规则”是场景规约或业务规则,可理解为系统的运作规则。
用户(读者)的心智模型不仅仅包含书,还应包含账号(图书卡)、书库(图书馆)等,模型有状态有行为,但其在参与场景进行交互时的受到场景规约的约束。
一种可以尝试的思路,是从业务规则(感知场景,从中提炼出的场景规约)中发现模型,并将业务规则与模型进行整体上的分离,让模型更自由,从而可能复用于不同的业务规则,或适应业务规则的变化。
至于模型的组织可以借鉴四色
原型的PPT
, 如图书馆的例子:Place(Library)、Party(Account)、Thing(Book), 或借鉴OO
的message-based的思路,将模型分类为object+message或event+handler/dispatcher;
当然,还有别的分类或组织模型的方法。
模型的使用者不应该被包含在模型内部。 ...
当你确定书是核心领域模型了,那么模型的使用者是不应该包含进来进行分析,通过借书这样一个事件
或场景的发生,模型的使用者与模型发生了关系,这时模型书还是需要一个使用者的记录的。
模型:
Class Book{
String id;
String name;
}
用户操作借书事件
激活借书服务,从而发生借书场景:
Class BookContext{
boolean borrow(Book book);
}
当borrow(Book book)事件被调用以后,拉了一泡屎,留下状态,这个书被借了,借阅者是某个用户,在数据表中我们可能有这样的记录:
book{
String id;
String borrowedUserId;
}
至于,这个borrowedUserId字段是否应该出现在Book模型中,则是另外一种设计考虑,比如我们认为borrowedUserId字段应该属于Book的状态,那么出现在BookState中比较合适,那么Book类有了一个新引用BookState:
Class Book{
String id;
String name;
BookState bookState;
}
Class BookState{
Book book;
User borrowedUser;
Date returnDate;//归还日期等
}
完毕。
我把整个过程列出来,是为了理清我们的思绪,不要让模型的状态去影响我们的分析。
以上这个分析的唯一前提是:假设这个系统是以书为核心,跟踪围绕书发生的各种事件
。
所以,我们在描述时不能以“书被借”这样去描述需求,会产生误导,因为“借书”是一个事件
,而“书被借”是一个状态,状态是事件
的结果,事件是状态的因,而模型是事件
的核心,没有模型,事件就无法发生,就象没有电话,就没有电话铃这个事件
,没有书,就不会有借书这样的事件
。
由以上倒退,我们知道,分析一个需求,核心模型是第一步,这一步是不应该考虑用户,前提是如果这个用户是在事件
发生时介入的话;但是如果这个用户不是事件
介入发生,而是属于模型一部分,如书的作者,那么就应该考虑用户。
我的观点是:天地不仁,以万物为刍狗。
千万不要以为是人就扔掉:驱动者和参与者的区别。在领域当中的“人”,与“刍狗”等同,没有特殊地位。在整个领域世界中,应该全是逻辑描述,即使是人,也应该以简单对象来理解,构成事实离不开万事万物。
试想一个互动功能,交朋友,没有任何独立于人的实物,把人扔掉会是什么样的效果呢?
理解驱动者与参与者区别,就可以走出误区,account很容易让人想到使用者,分开Passport和Reader不就行了?Reader是人吗?是,但他完全和Book的地位一样,“刍狗”一只而已。
“以用户为中心”的思想主要来自于登录系统——认为系统事件
参
与者就是现实世界中的用户。虽然这样的观点在一定程度上可行,但这种关联只是一个潜在的认为而已——经过登录后,认为某个现实用户(或者电脑,或者仪器,
或者IP)所发出的所有命令是系统中与这个登录所绑定的“人”发出的。这种关联是通过登录后获得,也就是说,若果没有登录,这两者应该是分离的,是两个独
立的个体。
发表评论
-
抽象类与接口选择
2013-12-06 00:20 846从设计理念层面看 abst ... -
深入浅出单实例Singleton设计模式
2013-09-11 00:14 714前序 单实例Singleton设计模式可能是被讨论和使用的 ... -
一些软件设计的原则
2013-09-11 00:12 684摘自http://coolshell.cn/arti ... -
API设计:用流畅接口构造内部DSL
2013-09-05 18:29 985摘自http://coolshell.cn/art ... -
性能调优攻略
2013-08-29 00:12 842转载自http://coolshell.cn/a ... -
软件级负载均衡器(LVS/HAProxy/Nginx)的特点和对比
2013-05-17 11:11 766现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升 ... -
大型网站架构演变和知识体系
2013-05-13 11:39 907源自http://www.blogjava.net/ ... -
webservice通信原理
2013-05-13 11:17 1072当前,WebService是一个热 ... -
为什么要使用EJB?
2013-04-23 10:17 481源于http://www.jdon.com/arti ... -
分布式Web服务器架构
2013-04-15 09:52 870最开始,由于某些想法 ... -
分布式架构关键技术
2013-04-15 09:51 1299分布式的概念 所谓分 ... -
海量数据处理系列(二)系统过载保护
2013-04-03 17:47 1435前言:前段时间在网上看到腾讯后台开发总监bison分享的一篇 ... -
关于软件的任务到底是什么的思考
2012-12-12 10:53 881摘自http://www.jdon.com/43127 ... -
应用架构设计的三个类型
2012-12-04 11:08 854转载http://www.jdon.com/43952 ... -
混合OO和Functional设计
2012-11-14 17:12 767摘自 http://www.jdon.com/43907 ... -
DCI架构是什么?
2012-11-12 17:19 1376摘自http://www.jdon.com/37976 ... -
DDD DCI和领域事件
2012-11-12 14:40 1612摘自http://www.jdon.com/jdonframe ... -
EDA事件驱动架构 领域事件 Event Sourcing
2012-11-12 10:11 2677摘自http://www.jdon.com/eda.html ... -
不变性immutablity设计
2012-11-08 14:39 1178摘自http://www.jdon.com/4296 ...
相关推荐
需求分析 需求工程 需求建模 需求 软件工程 需求分析建模
jtest domain领域建模工具
北邮软件工程分布式系统中需求定义,领域建模,用例建模等相关文档,写的不一定非常符合您的心意,仅提供参考。
DDD领域建模和TDD知识
《用户需求与系统建模》PPT教程,讲解透彻详细。
面向领域建模 DDD,精彩好书 !
领域建模领域建模文档-UML实践领域建模文档-UML实践
对于具备三、五年开发经验的同学而言,可能会接触到领域建模。如果公司规模较大,可能会更早接触这一概念。但是,领域建模好像一座高山,很难越过。目前,业界提出了很多方法建模,但没有一种被公认是最好的方法,大...
用户需求与建模这门课程中的一个实例----送餐管理系统
领域驱动设计、领域建模和架构说明、领域建模和架构说明
关于《用户需求与建模》这门课程的各个章节的有关课件
DDD 领域建模 资料
在真实的IT项目中,缺乏沟通的问题越来越大,但是这个问题却很少让我们注意,因为我们总是认为我们说的是同一种语言,大家都能够理解。其实不然,当我们说book review(书评) 时候,有的人把它解释成为editaral review...
领域驱动设计 DDD领域建模相关的概念 事件风暴 限界上下文 领域建模 设计经验实战示例 含内容如下: 操作手册 产出物图例 概念讲解
2023 软件需求工程与UML建模 15组 软件需求规格说明(.docx版)
获取阶段, 以用户易理解的图形化方式灵活直观地与用户进行需求交互, 根据用户定制的需求 自动生成具体应用的标准需求开发文档和开发过程中所产生的统一建模语言( UML, Unified ModelingLanguage), 并最终开发出用户...
非常好和最为全面的DDD领域建模知识总结资料并包含了简单样例代码解读,该资料包含8个部分 1. 什么是DDD? 2. 为什么要使用DDD? 3. DDD核心概念 4. DDD需求分析、设计、开发流程 5. 基于微服务架构构建旅程 6. DDD...
DDD领域建模和TDD相关知识
需求分析 数据模型 功能模型 行为模型 分析建模
关于敏捷建模软件等 随着软件工程快速的发展和深入,软件需求分析以及软件需求管理逐渐成为 软件开发过程中非常重要的活动。需求分析的质量对后续的软件开发各阶段有着 深远的影响。面对客户日益复杂多变的需求,...