前面的帖子很绕，我反思了一下，基本赞同banq关于“业务领域”和“领域模型”的说法。好了，DDD锵锵三人行继续开会。 我在百度百科上查了一下关于“领域”的定义：
研究领域 对某一科目分类划分后，对应的各部分就叫作某某领域。也可以称高级的领域。 ◎ 领域 lǐngyù (1) [territory;domain]∶一国主权所达之地 (2) [field;sphere;domain;realm]∶从事一种专门活动或事业的范围、部类或部门 字典中的意思 ①犹指领土。国家主权管辖下的区域：国家领域神圣不可侵犯。 ②意识形态或社会活动的范围：思想领域｜学术领域｜生活领域｜科学领域。 |
领域模型是领域专家和分析人员互相沉淀知识的一个工具，它帮助分析人员理解领域知识，也为领域专家提供一个规范的
表达形式，有条有理的描绘领域知识，分析、解决领域问题。另外，领域模型也是开发团队知识沉淀的一种方式，帮助开发人员
了解他所从事的特定领域，提高建模技能。
领域模型其实是一种语言，领域专家与分析人员、开发人员之间交流的通用语言。
1. 领域模型不是图，图只是让核心、关键的概念清晰的呈现出来。图的表达能力有限，模型必须配备描述（需求采集会议
中的口头描述，或文档中的文字描述），将图形所代表的意义，以及图形中没有呈现出来的规则、断言、细节进行补充，才能完
整地表述需求。
2. 领域模型的UML或者类UML图不能太细太完整，否则过于庞大的模型会干扰人的思维，阻碍对主要部分，或者复杂逻辑的
梳理。业务总是被切分成一个个片断进行分析，在每一个片断里，画出几个主要的对象和交互逻辑，细节的部分用文字记录、
描述。
3. 领域模型中不应当出现设计、技术方面的术语，也不应当出现开发人员不理解的业务术语。
|
@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修改过]
