前段时间看了DDD,最近在做一个项目的时候Leader要求先出E-R Model，我不是很清楚Domain Model和E-R Model具体的关系和区别。
E-R Model关注的是对象的实体和关系，是Data Modeling的一种方式，建模时并不考虑Entity的行为，在E-R概念模型的基础上可以建立relational data model及physical data model，我不太确认E-R model driven是否就是数据驱动的一种设计流程。
而Domain model driven同样是分析抽象实体并建立实体的关系的过程，同时需要建模实体的职责（对象的行为）,以面向对象的手法建立领域层的模型。
我有些迷糊，E-R model driven和Domain model driven 是否是冲突的，或者说可以柔和在一起，比如先建立conceptual e-r model,然后在这个模型的基础上再分别建立relational data model和domain model。但是跟随DDD的分析过程，我实在看不出有建立e-r model的必要，是否可以说，使用了domain driven design就可以不需要e-r model了呢（至少在建立domain model之前）？
evan 发表于2005-04-06 11:37 AM
花了点时间去了解了E-R model,domain
model,conceptual model，data modeling的关系与区别，收获颇丰。反过来看，自己之前对这些概念的理解还是比较肤浅的。
首先，需要了解“数据建模”和“对象建模”的概念、关系及区别。在某种层度上两者是具有一定的对立性的，孰幼孰劣即使是专家也众口不一。这里有一篇难得的好贴进行了大量的讨论 数据建模VS对象建模(http://www.hibernate.org.cn/viewtopic.php?t=1464&postdays=0&postorder=asc&start=0)
我们之前两周的工作，大家在概念上的不统一我想很大层度上是因为在这两者的理解上完全还是混淆的而造成的。
我们之前要求设计的E-R Model是属于数据建模的范畴，E-R Model是数据模型的一种表现形式(数据建模不只是E-R Model一种表现形式) ，E-R Model以数据为中心，关注的是对象的实体和关系，建模时并不考虑Entity的行为。在E-R概念模型的基础上可以建立“关系数据模型”进而推导出“物理数据模型”，这是一条以E-R Model为起始的数据建模的路线。 E-R Model的介绍请参看附件 “E-R Model(R).ppt ”。
值得注意的是，在扩展的E-R模型里面具有继承结构，同时以UML的形式也可以表现E-R模型，具体的介绍请参看附件“用UML表示的ER图.pdf”。不过在该领域内的专家Scott.W.Ambler提到"Unfortunately data modeling is not yet covered by the Unified Modeling Language (UML), even though persistence-related issues are clearly an important aspect of object-oriented software project. For several years I have argued that the UML needs a data model (Ambler 1997, Ambler 1997b, Ambler 2001a, Ambler 2002a) and have vacillated between various ways that it should be done."(详见 A UML Profile for Data Modeling http://www.agiledata.org/essays/umlDataModelingProfile.html ）
这个给我带来了些迷糊，以UML表示的ER图属于数据建模还是对象建模？而这好像正是我们之前两周工作中所面临的问题。
为什么要强调以UML表示的ER图属于数据建模还是对象建模，因为我们之前希望在UML表现的E-R图的基础上建立Domain Model和Relational Data Model，这是否是一条合理的路，或者说在什么情况下合理，我还很难判断。不过Domain Model是属于对象建模的范畴，它和E-R Model的分析具有很大的相似性，最大的区别我认为对象建模需要为对象建立职责（对象的行为），而正因为行为的存在衍生出时序、多态等等对象模型比之数据模型所特有的东西。 从《DDD》的建模分析推导过程，我实在看不出在建立Domain Model之前有建立E-R Model的必要性。但是正如上面帖子里所讨论的，数据建模优先还是对象建模优先，对专家级别的人来说也是由其经验和偏好所决定的。在CMS项目里面，我觉得数据模型上的复杂度并不是很高，我想Domain Model优先可能合适一点。Domain Model到什么地步才会有数据模型或者是关系数据表能确定？我想还是在对象和其属性大致确定的时候比较合适。
最后，我们还提到了概念模型（conceptual model)，容易让人混淆的是不管是数据模型还是对象模型都会有 概念的层面。在数据建模中通常将E-R Model就称之为概念数据模型（接下来的层面是关系数据模型和物理数据模型）；在对象模型中，对象图通常是从粗到细具有不同的level，可以将只考虑对象实体的划分和关系的建立的层面称之为概念模型（可参考《Analysis Pattern》)
希望若干时间以后我会觉得上面的理解还是很肤浅。
model,conceptual model，data modeling的关系与区别，收获颇丰。反过来看，自己之前对这些概念的理解还是比较肤浅的。
首先，需要了解“数据建模”和“对象建模”的概念、关系及区别。在某种层度上两者是具有一定的对立性的，孰幼孰劣即使是专家也众口不一。这里有一篇难得的好贴进行了大量的讨论 数据建模VS对象建模(http://www.hibernate.org.cn/viewtopic.php?t=1464&postdays=0&postorder=asc&start=0)
我们之前两周的工作，大家在概念上的不统一我想很大层度上是因为在这两者的理解上完全还是混淆的而造成的。
我们之前要求设计的E-R Model是属于数据建模的范畴，E-R Model是数据模型的一种表现形式(数据建模不只是E-R Model一种表现形式) ，E-R Model以数据为中心，关注的是对象的实体和关系，建模时并不考虑Entity的行为。在E-R概念模型的基础上可以建立“关系数据模型”进而推导出“物理数据模型”，这是一条以E-R Model为起始的数据建模的路线。 E-R Model的介绍请参看附件 “E-R Model(R).ppt ”。
值得注意的是，在扩展的E-R模型里面具有继承结构，同时以UML的形式也可以表现E-R模型，具体的介绍请参看附件“用UML表示的ER图.pdf”。不过在该领域内的专家Scott.W.Ambler提到"Unfortunately data modeling is not yet covered by the Unified Modeling Language (UML), even though persistence-related issues are clearly an important aspect of object-oriented software project. For several years I have argued that the UML needs a data model (Ambler 1997, Ambler 1997b, Ambler 2001a, Ambler 2002a) and have vacillated between various ways that it should be done."(详见 A UML Profile for Data Modeling http://www.agiledata.org/essays/umlDataModelingProfile.html ）
这个给我带来了些迷糊，以UML表示的ER图属于数据建模还是对象建模？而这好像正是我们之前两周工作中所面临的问题。
为什么要强调以UML表示的ER图属于数据建模还是对象建模，因为我们之前希望在UML表现的E-R图的基础上建立Domain Model和Relational Data Model，这是否是一条合理的路，或者说在什么情况下合理，我还很难判断。不过Domain Model是属于对象建模的范畴，它和E-R Model的分析具有很大的相似性，最大的区别我认为对象建模需要为对象建立职责（对象的行为），而正因为行为的存在衍生出时序、多态等等对象模型比之数据模型所特有的东西。 从《DDD》的建模分析推导过程，我实在看不出在建立Domain Model之前有建立E-R Model的必要性。但是正如上面帖子里所讨论的，数据建模优先还是对象建模优先，对专家级别的人来说也是由其经验和偏好所决定的。在CMS项目里面，我觉得数据模型上的复杂度并不是很高，我想Domain Model优先可能合适一点。Domain Model到什么地步才会有数据模型或者是关系数据表能确定？我想还是在对象和其属性大致确定的时候比较合适。
最后，我们还提到了概念模型（conceptual model)，容易让人混淆的是不管是数据模型还是对象模型都会有 概念的层面。在数据建模中通常将E-R Model就称之为概念数据模型（接下来的层面是关系数据模型和物理数据模型）；在对象模型中，对象图通常是从粗到细具有不同的level，可以将只考虑对象实体的划分和关系的建立的层面称之为概念模型（可参考《Analysis Pattern》)
希望若干时间以后我会觉得上面的理解还是很肤浅。
evan 发表于2005-04-06 6:34 PM
和MZhou有一段Mail的交流,以XP和RUP的角度去进行了下区分,希望没有打什么诳语
MZhou:
----------------
Domain Model翻过来是领域模型吧
你需要好好学习学习UML结合RUP过程做项目。因为Rup过程第一大步基本就是领域建模，然后是用例模型，然后是分析模型、对象模型，然后是数据模型。
当然，对于画这几个模型的先后顺序，其实并没有定论，否则RUP就不会那么强调迭代了。当然，对某一个具体的模型，那么肯定是先有领域模型、再有对象模型、再由数据模型。整体项目而言，这些模型就是迭代，项目完快结束了可能还在修改领域模型。
Evan:
--------------------
我的Domain Model是《DDD》里面的概念，我想它和你提到的RUP里面的领域模型应该是有二仪性的，感觉“我的Domain Model”属于对象建模的范畴，“你的领域模型”属于数据建模的范畴（虽然是UML的表现）
我感觉《DDD》在倡导一种XP的风格，而XP本身就颠覆了RUP的很多内容。可能需要同时把这两者都稍微消化消化，才能很好的进行理解和区分，而我，当前正处于消化不良的阶段。
MZhou:
----------------
Domain Model翻过来是领域模型吧
你需要好好学习学习UML结合RUP过程做项目。因为Rup过程第一大步基本就是领域建模，然后是用例模型，然后是分析模型、对象模型，然后是数据模型。
当然，对于画这几个模型的先后顺序，其实并没有定论，否则RUP就不会那么强调迭代了。当然，对某一个具体的模型，那么肯定是先有领域模型、再有对象模型、再由数据模型。整体项目而言，这些模型就是迭代，项目完快结束了可能还在修改领域模型。
Evan:
--------------------
我的Domain Model是《DDD》里面的概念，我想它和你提到的RUP里面的领域模型应该是有二仪性的，感觉“我的Domain Model”属于对象建模的范畴，“你的领域模型”属于数据建模的范畴（虽然是UML的表现）
我感觉《DDD》在倡导一种XP的风格，而XP本身就颠覆了RUP的很多内容。可能需要同时把这两者都稍微消化消化，才能很好的进行理解和区分，而我，当前正处于消化不良的阶段。
evan 发表于2005-04-07 8:39 AM
think的mail 回复
-------------------------
“领域模型”指的是该模型描述的是现实业务领域，而不是要开发的软件系统中的类。当然，往往现实中的概念会直接映射到系统中。
E/R模型是用数据存储方式来表达领域概念的一种方法，也可以用ER图来表示领域模型。但“数据库建模＋编写过程操作数据库”（面向过程）和“用对象封装同源的数据和行为”（面向对象）的思维方法是不一样的，对象方法就是要解决软件的复杂性问题。现代的工具中，数据库的概念模型和物理模型完全可以从类图直接生成，如果采用对像方法，没有必要再去思考ER模型。
Domain model driven说的是如何通过深化领域模型来驱动对业务的理解。
-------------------------
“领域模型”指的是该模型描述的是现实业务领域，而不是要开发的软件系统中的类。当然，往往现实中的概念会直接映射到系统中。
E/R模型是用数据存储方式来表达领域概念的一种方法，也可以用ER图来表示领域模型。但“数据库建模＋编写过程操作数据库”（面向过程）和“用对象封装同源的数据和行为”（面向对象）的思维方法是不一样的，对象方法就是要解决软件的复杂性问题。现代的工具中，数据库的概念模型和物理模型完全可以从类图直接生成，如果采用对像方法，没有必要再去思考ER模型。
Domain model driven说的是如何通过深化领域模型来驱动对业务的理解。
evan 发表于2005-04-07 8:46 AM
在"豆豆他爹"的blog里面看到这样的描述,解惑啊
---------------------------
我不是很清楚你说的PD是什么，是指领域模型（Domain Model）吗？ 如果是的话，请看下面我的理解，如果不是，就别看了。
从fdd的资料中，你可以看出，fdd的第1步有两点：1需要domain expert 进行领域走查 2 可以参考用例或者其他形式的需求文档那么，也就是说，fdd关注点是从需求以后的。需求以后的，就是分析和设计啦。
那么我们在看一下你说的业务模型是什么。它是对业务流程中的交互实体的抽象。在rup中，称其为business object model。由于软件系统要对业务流程进行实现（或者进行改进实现），那么业务对象模型也基本会演化成细的计算机模型。在分析阶段的领域模型虽然比业务对象模型细，但还是比设计阶段的领域模型粗点。注意，分析阶段的领域模型，rup中叫分析模型，设计阶段的领域模型，rup中叫设计模型。这就是领域模型由粗到细的精化过程。
在up中，领域模型是一个综合的称谓，包含了业务对象模型，分析模型和设计模型。 领域模型，它的英文是domain model ，而domain，又来源于 problem domain （问题域）这个词组，也就是说，up 对领域模型的命名还是比较准确的。fdd中的领域模型，也可以认为是这个含义。我个人也非常倾向于把这3模型统称为领域模型。因为这样我们的思维才是连续的。
当然，在精化的过程中，有的领域对象会消失或者是分解，这不应影响你对领域模型（这个名字所包含的边界）的理解。
---------------------------
我不是很清楚你说的PD是什么，是指领域模型（Domain Model）吗？ 如果是的话，请看下面我的理解，如果不是，就别看了。
从fdd的资料中，你可以看出，fdd的第1步有两点：1需要domain expert 进行领域走查 2 可以参考用例或者其他形式的需求文档那么，也就是说，fdd关注点是从需求以后的。需求以后的，就是分析和设计啦。
那么我们在看一下你说的业务模型是什么。它是对业务流程中的交互实体的抽象。在rup中，称其为business object model。由于软件系统要对业务流程进行实现（或者进行改进实现），那么业务对象模型也基本会演化成细的计算机模型。在分析阶段的领域模型虽然比业务对象模型细，但还是比设计阶段的领域模型粗点。注意，分析阶段的领域模型，rup中叫分析模型，设计阶段的领域模型，rup中叫设计模型。这就是领域模型由粗到细的精化过程。
在up中，领域模型是一个综合的称谓，包含了业务对象模型，分析模型和设计模型。 领域模型，它的英文是domain model ，而domain，又来源于 problem domain （问题域）这个词组，也就是说，up 对领域模型的命名还是比较准确的。fdd中的领域模型，也可以认为是这个含义。我个人也非常倾向于把这3模型统称为领域模型。因为这样我们的思维才是连续的。
当然，在精化的过程中，有的领域对象会消失或者是分解，这不应影响你对领域模型（这个名字所包含的边界）的理解。
evan 发表于2005-04-07 9:15 AM
Fragment of preface in <<Analysis Pattern>>
-----------------
This is an object-oriented book, and I do not hesitate in proclaiming my belief
that the object-oriented approach is the superior way to develop software. These
models, however, are primarily conceptual models, and many data modelers
have had a long tradition of using conceptual (or logical) models. Data modelers
should find many of the patterns useful, particularly if they use more advanced
semantic techniques. The object-oriented features of the models will reveal many
of the differences between object-oriented and traditional approaches. I would
encourage such readers to use this book in conjunction with an OO analysis book
that stresses the conceptual side of modeling and the links between OO and
semantic data modeling.
-----------------
This is an object-oriented book, and I do not hesitate in proclaiming my belief
that the object-oriented approach is the superior way to develop software. These
models, however, are primarily conceptual models, and many data modelers
have had a long tradition of using conceptual (or logical) models. Data modelers
should find many of the patterns useful, particularly if they use more advanced
semantic techniques. The object-oriented features of the models will reveal many
of the differences between object-oriented and traditional approaches. I would
encourage such readers to use this book in conjunction with an OO analysis book
that stresses the conceptual side of modeling and the links between OO and
semantic data modeling.
evan 发表于2005-04-07 9:19 AM
可见 UML表示的ER图和RUP里面最早分析出的领域模型是不一样的.虽然非常接近,但前者属于数据建模的范畴，后者属于对象建模的范畴.我想,前者易造成混淆,是不值得推荐的
