ER图中的E是不是DDD中的实体呢

数据不是DDD的核心，数据库的E和DDD的E，形似但神不似。从形比较掌握不了DDD。出发点不同，还是不建议这样比较。
[该贴被SpeedVan于2011-04-12 13:35修改过]

所以我说仓储是领域为中心的思考，它放进去拿出来的都是聚合根，没有所谓的数据。

大家都说，对像是活的，它有生命周期，它有它的行为和属性，当我们暂时不用一个对像的时候，让它在仓储里待命，到这我是全完赞成，并且能这样理解让我折服，但我要如何实现这个仓储呢，如果我选择了DB作为实现的手段，这个时候，实体对像，是不是就可以理解成，它仅仅是个（数据+类型）的组合体呢，然后我们将类型当成TABLE_NAME，把数据变成一条记录，我这样去设计合不合理呢，如果合理，那ER图中的E和DDD中的E，企不是一样东西，如果不合理，那我又该如何设数据库呢，还请前辈们再给点一点，我在日本买不到中文完整版的DDD书，所以并未真正读过，如果我的想法可笑无知，还请谅解啊

若果你的表库结构是根据DDD中思维或者说是相同的思维，那么可以这么理解：表和类是对同一样的东西的不同描述。但是不同的描述有各自的特点，你可以理解他们描述同一样东西，而不能理解他们是同一个东西。一条记录是静态的数据，而聚合根是包含逻辑在内的，一条数据如何体现逻辑呢？当然数据库有他的实现逻辑方式，但是若果这样的话，还需要OO或者DDD么？直接一个REST+数据库就可以了。

数据库你可以理解为实体沉睡的地方（领域当中是活的，醒着的，所以实体沉睡的地方领域以外的地方——领域模型是描述现实逻辑，不是描述数据的增删改）。数据库中实体没有职责概念，因为它是睡着的，什么都不用做。

其实，我个人认为，引入CQRS的状态一词更好解析，数据库只是一个实体状态表而已，实体概念只存在领域中。

不信的话，激进一点，不管效率，直接用SQL语言写个东西看看，比OO更符合现实，更灵活。

OO所描述的就是现实，只是在现实当中套圈圈——边界思维。相比要把现实打散为数据的思维，还真不知道这种转换好在什么地方。还有劳表述一下在你眼中的数据库思维。

注：SQL对应的不是OO，用语言跟思维作对比，真不知道如何对比。若果你是说JAVA，还是那句：别拿JAVA=OO。

OO之所以搞出一大堆模式，起因就是这个中心搞错了。只有关系才能正确的描绘世界。

看看两者的理论基础，高下立判，关系数据库以集合论为基础，OO理论纯粹就是个山寨，无爹无娘。

其实我们生活当中就有很多模式，OO搞出模式都是源自生活当中，只是把一种常用的模式，进行起名，方便表达。JAVA上很多模式都是用代码表达，但这些模式是可以上升到语言层次的，到时，你还会说很多模式么？别把模式上升了，就看不见模式。可以这么说模式就是一种逻辑。

补充一点：正确与否不是看爹娘的，而是否逻辑严密，难道说个个都必须是“我爹是李刚”，呵呵，说笑
[该贴被SpeedVan于2011-04-14 17:32修改过]
[该贴被SpeedVan于2011-04-14 17:43修改过]

撇开架构之争，首先就要厘清分析中谈及的“对象”（或实体）是软件对象还是现实世界对象，以及它们如何对应。

毫无疑问，现实世界中的对象是不带有自己的“方法”的。（在这个上下文中，现实世界是相对于软件之外而言的）
[该贴被flyingrobot于2011-07-13 22:12修改过]

这需要你怎么看，现实世界中的对象是有边界的，当边界划定的时候，也就可以带有自主方法（不一定有，但可以带有）。没有边界的对象是不存在的。

“边界”这个词，还是用于“域”比较好。对象、实体，更适合用“确定性”来限制。有些实体/对象，可能受“域”边界的影响，有些则不。