对领域驱动设计的初步认识（十）

前面的帖子很绕，我反思了一下，基本赞同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;

	... ... 
}

同样在那个微博里还有一个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;

	... ... 
}

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

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

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修改过]

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

哎，没办法。我所在的企业里已经树立很多系统，其中大部分都是自己的开发的，因为国外的软件水土不服。到现在，领导和用户对集成的要求越来越高，认为“业务已经存在于各个系统了，只要集成一下就可以了”。所以我现在在研究整个企业的业务建模问题，所以看待企业的业务已经不是按照通常单业务的方式，而是研究企业的整体结构以及各个业务的关系。其实这也是一个非常大的商机，不过也很难做，比如IBM也只做咨询。
我正着手打算创建一个企业基础管理平台，是面向开发者的，不是市面上那种骗人的快速开发平台，在技术架构上打算采取jdon+resteasy+extjs+ejb+mule3+CAS+portal(没定）+工作流（没定）

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

  其实我们可以反思一下过去的领域建模过程，一个所谓的“业务领域”并不是单一的业务领域，而是众多子领域相互作用的结果。可是我们习惯于在这个所谓的“单一业务领域”里突出我们认为的“重点子域”，而忽视其他的子域，甚至同时把其他的子域也认为都是那个“重点子域”里不可或缺的东西。jivejdon里的Account就是这样来的。呵呵，我有点放马后炮。这样的事情自己也干了不少。
  比如我们对一个“手的动作”进行分析研究，按照惯例我们会认为这就是一个“手”而分析“手”的各种功能。这里面其实还有“脑”的控制作用，可是我们往往会把“脑”认为是一种参与，把脑和脑的功能都放到“手的动作”这个业务领域里，最终构建出“手的动作”这个系统。其实很多小系统都是这样的，麻雀虽小，五脏俱全。从领域角度看，一个业务系统往往是多个领域相互作用的结果。但是考虑到进度、成本各方面的因素，没人会真正按DDD的方式干。呵呵，说好听点是符合节能减排；说难听点是只管GDP，不管CPI。如果按照这种思路对人体的各个部分分别建模，从表面上弄出来的是“手、足”什么的；但是仔细分析这些所谓的“手、足”系统，发现这些“手、足”其实不是真正的“手、足”器官，还会有其他的器官比如“脑”的功能，也就是所谓“四不象”。所以想把这些“手、足”器官想拼接成一个完整的人，是完全不可能的。
  另外，对于初学者来说，我不建议去学DDD。这就好像大人教育孩子要这样那样，可是孩子会当回事吗？只有孩子自己在外面摔得头破血流的时候才会想起父母的话。所以先不要急于学习DDD，首先应该学会如何分析业务，这也是能够真正用好DDD的关键。在小说里，我常常看到这样的例子，小时候经历过各种磨难的孩子在学习和机会的把握上都要强于别人。
[该贴被flyzb于2010-12-19 10:50修改过]

2010年12月18日 10:32 "banq"的内容

1.除非一个模型在逻辑上一致，否则没有任何意义，在理想世界里，我们会拥有涵盖全部企业领域的单个模型。
2.实现大型项目领域模型的完全统一是不可行的或者代价太高。
3.大型项目都采用多模型进行开发。 ...

的确，这非常难。但是，对于我和同事们来说，这是必须要解决的问题。我们单位在整个集团都属于信息化标杆企业，所以外在和内在的压力迫使我们必须正视这个事情。从企业信息化咨询和整体业务架构建模来说，一些国内的企业比如金蝶、用友都有相关的业务，但不满足我们的要求，甚至还不如我们。而国外的企业比如IBM因为不了解中国的企业，所以只能采用其思想。目前我一直在思考如何在企业里构建业务组件，这是实施SOA的关键。从企业宏观层面来讲，CBM的确博大精深；从微观层面来讲，DDD是对CBM的有益补充。

2010年12月19日 11:04 "flyzb"的内容

这是实施SOA的关键。从企业宏观层面来讲，CBM的确博大精深；从微观层面来讲，DDD是对CBM的有益补充。 ...

对CBM不太了解，不过也要防止"赵本山卖拐"现象发生，因为宏观的东西都是一样的，越宏观，离微观落实越远，这是我基本信条；类似电信行业有NGOSS和BOSS，其实就是领域模型+SOA。

人在江湖，身不由己，不过，你们既然系统已经存在，而且已经运行多年，那么来一次整体重构设计集成是可以考虑的，如果大型系统刚刚开始就没有必要了。

从全企业的角度进行整体建模非常难，所以我一直在寻找分析建模方法。CBM从本质上来说和DDD没有区别，都是强调业务组件（对象）的划分，只是颗粒度不同。不管宏观或者微观，都是域的划分，关键是如何认识“业务”是不同“业务领域”相互作用的结果。对于域的划分，我觉得DDD本身没有问题，但是我们在实际建模过程中贯彻的不够彻底。

CBM介绍
 基于 CBM, SIMM 和 SOMA 的 SOA 的最佳实践

DDD回答了“在业务领域划定之后的建模问题”，但没有回答“业务领域是如何划分的“的问题，对于后者CBM也许是个答案。
[该贴被flyzb于2010-12-20 13:06修改过]

2010年12月20日 13:02 "flyzb"的内容

DDD回答了“在业务领域划定之后的建模问题”，但没有回答“业务领域是如何划分的“的问题，对于后者CBM也许是个答案。 ...

产品服务资源模型不只是CBM，NGOSS等BOSS系统都使用这些，你手机上定制一个彩铃，名目繁多的收费服务，后台都是由BOSS这样平台给你计费管理，CBM其实就是这种平台，看下图NGOSS的分类，是不是和CBM意思很像(见我的NGOSS与领域建模)，哈哈：

刚刚看到一篇新闻，IBM的Websphere很厉害吧？难得一见的中间件产品，是IBM务虚中拿得出手的大作品，今天Websphere创始人在BBC回答记者提问：他一生中最大的错误就是WebSphere:
http://www.bbc.co.uk/news/business-11944966

厂商总是以帮助你简化为幌子，导入更多的复杂，他认为：引入云服务是简化的一个步骤，现在SOA真的已经OUT了，组件服务的概念被云替代了：SOA is Dead; Long Live Services（SOA已死，服务万岁），而CBM中还在机械地标识服务启动服务这些琐碎昂贵的恐龙步骤，REST其实就够了。

[该贴被banq于2010-12-20 14:44修改过]

2010年12月18日 00:47 "flyzb"的内容

只有在不同的企业里分析同一个业务才能更清醒地抓住业务的本质 ...

业务的本质是什么？或者领域模型的本质是什么？
[该贴被xuzhh于2010-12-20 17:47修改过]

2010年12月20日 16:19 "xuzhh"的内容

2010年12月18日 00:47 "flyzb"的言论
只有在不同的企业里分析同一个业务才能更清醒地抓住业务的本质 ...

业务的本质是什么？或者领域模型的本质是什么？ ...

注意，业务不是死的，在不同的组织和管理文化下，同样一种业务会表现出不同的特点，尤其在中国这会更加明显，有一句老话“在变化中把握规律”。

    呵呵。。。对于CBM来说，组件框架只是结果，更重要地是它是一种企业级的业务架构分析方法，这和技术完全没有关系，用rest或者其他的实现都可以。
    DDD告诉我们应该如何用丰富的对象来进行领域建模；而CBM告诉我么如何用不同的业务领域来构建整体业务。
    另外，banq，我感觉“领域模型+分布式”不能完全替代SOA的地方是“好像没有地方去注册领域模型的服务”。如果没有这点，不同的团队如何完成协作，不同的领域模型如何集成。其实也就是现在DDD的服务和事件还不够强壮，不能替代ESB。
[该贴被flyzb于2010-12-20 22:00修改过]

2010年12月20日 20:19 "flyzb"的内容

注意，业务不是死的，在不同的组织和管理文化下，同样一种业务会表现出不同的特点，尤其在中国这会更加明显，有一句老话“在变化中把握规律”。 ...

那就请banq说说，他说过领域模型是稳定的，你难道没有记住。