对领域驱动设计的初步认识(十)

10-12-18 flyzb
  前面的帖子很绕,我反思了一下,基本赞同banq关于“业务领域”和“领域模型”的说法。好了,DDD锵锵三人行继续开会。

  我在百度百科上查了一下关于“领域”的定义:

  
研究领域
  对某一科目分类划分后,对应的各部分就叫作某某领域。也可以称高级的领域。
  ◎ 领域 lǐngyù
  (1) [territory;domain]∶一国主权所达之地
  (2) [field;sphere;domain;realm]∶从事一种专门活动或事业的范围、部类或部门
  字典中的意思
  ①犹指领土。国家主权管辖下的区域:国家领域神圣不可侵犯。
  ②意识形态或社会活动的范围:思想领域|学术领域|生活领域|科学领域。

  从上可以看出,这与banq说“业务领域就是边界”基本相同。不过我还是提出疑问,为什么业务领域会有边界呢?如何确定边界的大小呢?那就是领域模型,那我们再看看领域模型的定义: 

    领域模型是领域专家和分析人员互相沉淀知识的一个工具,它帮助分析人员理解领域知识,也为领域专家提供一个规范的
表达形式,有条有理的描绘领域知识,分析、解决领域问题。另外,领域模型也是开发团队知识沉淀的一种方式,帮助开发人员
了解他所从事的特定领域,提高建模技能。
    领域模型其实是一种语言,领域专家与分析人员、开发人员之间交流的通用语言。
    1. 领域模型不是图,图只是让核心、关键的概念清晰的呈现出来。图的表达能力有限,模型必须配备描述(需求采集会议
中的口头描述,或文档中的文字描述),将图形所代表的意义,以及图形中没有呈现出来的规则、断言、细节进行补充,才能完
整地表述需求。
    2. 领域模型的UML或者类UML图不能太细太完整,否则过于庞大的模型会干扰人的思维,阻碍对主要部分,或者复杂逻辑的
梳理。业务总是被切分成一个个片断进行分析,在每一个片断里,画出几个主要的对象和交互逻辑,细节的部分用文字记录、
描述。
    3. 领域模型中不应当出现设计、技术方面的术语,也不应当出现开发人员不理解的业务术语。

  领域模型是领域核心,是决定领域边界的关键。不过我感觉领域模型有内涵和外延之分。上面关于领域模型的定义,我感觉更多说的属于外延部分。因为业务是变化的,那么领域模型也会发生变化,关键是我们要掌握驱动业务变化的核心,即驱动领域模型变化的核心。

  以jivejdon为例,其业务领域是"人与人之间的思想交流",其领域模型的核心是"如何让人与人之间能够便捷地进行思想交流",其领域模型的功能(外在表现)为"发表观点(发帖)、发表评论(回复)、热点订阅"等等。为什么我特意把领域模型分解为核心和功能两个部分,就是强调在做领域建模的时候要能够在不同场景下判断出领域模型会出现什么不同的变化。只呆过一个企业的领域专家不是真正的领域专家,只有在不同的企业里分析同一个业务才能更清醒地抓住业务的本质。

  在上个帖子里,我提到了"客观主体",banq不太理解。其实在IBM的CBM(业务组件模型)理论中,一个业务组件(CBM)包含三个维度:业务能力、组织和流程。我说的"客观主体",也可以说是业务主体,指的就是人或者组织。这和DCI中的角色是不是一层面的东西。如果想做企业信息化规划(最值钱的东西,可是国人不认),必须对企业人或组织有深入的研究。呵呵,IBM实施CBM是很贵的,随便一下绝不少于百万的。其实CBM属于宏观层面的业务建模,而DDD属于领域层面的建模。

  关于那个Acount的问题,banq还是没明白我的意思,那我进一步说明一下。假如领导让我先开发了一个jivejdon系统,又让另外一个人开发了一个微博系统,可是后来领导希望我们把2个系统整合到一个系统,会遇到如下业务集成的问题:

jivejdon里有一个account,代码如下:

@Model
public class Account {

	private String userId;

	private String password;

	private String username;

	private String email;

	private String roleName;

	private boolean emailVisible;

	private boolean emailValidate;

	private String creationDate;

	private String modifiedDate;

	private String postIP;

	private AccountMessageVO accountMessageVO;

	... ... 
}
         
<p>

同样在那个微博里还有一个Account对象

@Model
public class Account {

	private String userId;

	private String password;

	private String username;

	private String email;

	private String roleName;

	private boolean emailVisible;

	private boolean emailValidate;

	private String creationDate;

	private String modifiedDate;

	private String postIP;

	private AccountBlogVO accountBlogVO;

	... ... 
}
         
<p>

那么大家可以思考一下该如何整合这两个系统?整合的结果又说明了什么?

注:也许有人对我为什么对业务、领域、模型这么简单的几个东西,反反复复说来说去,认为这些就是天经地义的东西。在对于如何对十分复杂的企业业务建模的过程中,我发现就是这么几个看起来简单的东西是困扰我抓住业务本质的障碍,就好像在探寻“1+1”的问题一样。我坚信"简单的背后不简单".

[该贴被flyzb于2010-12-18 10:20修改过]

         

4
banq
2010-12-18 10:32
2010年12月18日 00:47 "flyzb"的内容
领导让我先开发了一个JiveJdon系统,又让另外一个人开发了一个微博系统,可是后来领导希望我们把2个系统整合到一个系统, ...

整合分设计整合和数据整合,在微博没有开发成功运行多月之前,不要进行设计整合,这时可以数据整合。

让两个Account之间进行数据交换,反正里面格式差不多,这个转换工作不难。

在我之前的帖子我已经举例DDD中限界上下文集成的例子,DDD作者原来只做一个routing Service,后来再做一个类似的NetworkTraveralService用于另外一个领域,然后在这两个之间做数据转换,划清边界。(Page 265)

我再把DDD作者关于集成 整合的话摘录如下(原书都是黑体):

1.除非一个模型在逻辑上一致,否则没有任何意义,在理想世界里,我们会拥有涵盖全部企业领域的单个模型。

2.实现大型项目领域模型的完全统一是不可行的或者代价太高。

3.大型项目都采用多模型进行开发。

4.明确定义模型应用的上下文,设置界限,在这些界限中保持模型严格的一致性。

5.其他人对上下文(场景)界限不清楚的人,会不知不觉改变界限,使其边缘模糊或者两者变成复杂的衔接。在限界场景之间重用代码是一种冒险。

说白了,大型系统的业务组件的重用想不别想,至少在成功运行多年后才会启动重构。

不知我的回答是否是你的疑问,呵呵。

[该贴被banq于2010-12-18 10:39修改过]

SpeedVan
2010-12-18 12:21
这种整合只是偶然的状况,也就是极为相似的状况。独立开发的两个系统,没有任何预兆,突然合并,肯定是高付出的(没有统一标准),建议如banq所说,先独立运行吧,稳定后某一天,再作出整合的决策。

flyzb
2010-12-18 22:22
  哎,没办法。我所在的企业里已经树立很多系统,其中大部分都是自己的开发的,因为国外的软件水土不服。到现在,领导和用户对集成的要求越来越高,认为“业务已经存在于各个系统了,只要集成一下就可以了”。所以我现在在研究整个企业的业务建模问题,所以看待企业的业务已经不是按照通常单业务的方式,而是研究企业的整体结构以及各个业务的关系。其实这也是一个非常大的商机,不过也很难做,比如IBM也只做咨询。

  我正着手打算创建一个企业基础管理平台,是面向开发者的,不是市面上那种骗人的快速开发平台,在技术架构上打算采取jdon+resteasy+extjs+ejb+mule3+CAS+portal(没定)+工作流(没定)

flyzb
2010-12-18 23:12
  其实对于上面那个Account的问题,我曾经仔细研究过。banq曾反复地指出面向数据库的伪对象问题。为什么“基于数据表的对象”有问题?因为随着业务的复杂,“基于数据表的对象”会变得十分脆弱,不能适应业务变化。那么什么样的设计才能适应复杂的业务变化呢?DDD给出了答案,进行细粒度的领域特征建模。banq举的那个“订单和订单交货”的例子就说明了这点。我经过反思后发现,不同系统的业务难以集成的原因就是我们没有完全按照DDD的方式建模,对业务领域区分对不够。如果不同的系统都能够完全遵循DDD建模,那么业务集成就不成问题。对于jivejdon的Account,我是这样分析的。jivejdon的业务领域是“人与人的思想交流”,那么首先要做子域切分:“人”和“思想交流”。其中“人”就是人员管理,是一个独立的子域,不含任何jive的成分。另外一个子域里包含2个部分:“人的参与”和“交流”。从这可以看出,用好DDD的关键是能够真正对业务进行细粒度的正确切分。我建议不要把完全依赖领域专家,自己至少是半个领域专家。呵呵,这些东西说起来简单,可是业务和技术都懂的人太少了。

猜你喜欢
5Go 1 2 3 4 ... 5 下一页