看过《领域驱动设计》一书后的疑惑

数据这层你根本不用管，交给ORM去做。要改动也是改改配置文件，没有什么大动作。

似乎没那么简单吧，我觉个例子说明一下可能会更容易理解些。

比如：原来根据领域模型A、B类通过ORM工具自动生成了表TA、TB，现在领域模型有了变化，变成三个类C、D、E，这个C、D、E类与表TA、TB之间的关系就不那么协调一致了。

我想问的是，当遇到这样情况时，该怎么做？我想不会是简单改下Hibernate的配置文件就能实现的吧

自己顶一下，希望能得到大家更多的意见

这有何难，以前的TA TB是系统自动生成的。你现在没有了A,B当然要手工把TA ,TB删除了。ORM会根据你的C,D,E自动生成TC TD TE。就是说你不要去想手工建表，手工维护表关系。都丢给ORM去做。A,B改变到C,D,E那么以前的A.hbm.xml B.hbm.xml自然要删除，写C.hbm.xml D.hbm.xml E.hbm.xml，系统在初始时会扫描你的hbm.xml文件来生成新的表。都不关你事，你只要写好hbm.xml配置文件。
[该贴被goddie于2008-03-06 15:08修改过]

首先非常感谢goddie兄的回复，通过hbm.xml自动生成数据库表的方式在系统没有上线运行的情况下是可行的，但对于一个已上线运行的系统，数据的迁移怎么解决呢？

数据库和业务模型是两个不同的结构，不需要一一对应，所以你只要写一层Adaptor适配数据库和业务对象。
这也就是是说一个业务对象可能是一个表，也可能是多个表的组合，但是从业务上来讲，我们不需要关系数据库

我现在也比较关心数据迁移的工作.在针对业务的变化可以将数据层的变化交给Mapping工具去做,而需要兼容现有系统的时候,问题就会比较多.我个人感觉还是需要DBA保证数据的安全.
但对于程序人员可以不考虑这部分.

有没有其他更好的思路?

对于领域建模中的仓储始终看不太明白，哪位看懂的能不能解释一下？万分感谢！

我也有和lz一样的问题，困惑很久，也在其他帖子里提到过，但是都没人回答。

>是不是会造成领域层与数据层之间的不一致，这个不一致对于软件的维护会不会带来影响？

这个就由一些ORM框架完成，比如Hibernate等，如果是JDBC就只好自己手工完成，这就是对象和数据库不匹配的烦恼。

除非一开始你能想到所有的因素，否则持久化层一定会变化。至于变化的多寡确实很难判定。

是否可以设计建模用DDD，具体实现的时候，我指的是持久化这部分，不用Hibernate等ORM框架，而是采用一种可以自己控制数据库结构和SQL语句的方法（比如iBatis，也许不行，没仔细研究）。这样既可以发挥DDD分析描述问题的长处，也可以发挥传统数据库技术的优势。同时尽量保持数据库稳定。

如果需求是变得，那么模型必然也是变的。模型是变的怎么能够要求持久化成的东西不变那？？
不过我比较喜欢自己实现持久化的过程，这样更加可控。

需求变化？需求变化可以粗略分两大类：与数据结构有关的及与数据结构无关的。如果是前者，没办法，只好“雄关漫道真如铁，而今迈步从头越”。因此，老手们经常有这样的感叹：数据一定得规划好啊，不然会倒大霉的。