Key-value存储，图数据去查询？
Product下的某个具体属性特征，影响到了Product对某些Part的选取或装配，这个关系又怎么定义？

这两个问题我感觉应该是让领域层去完成，比如查询通过仓储层，比如Product 的Id为888，那么到图库查Key为888的，再到HBase查key也为888的，两者在仓储组装还原成领域模型Product即可。

关于“某个具体特征影响到了Product某个具体Part的装配”，这个涉及到一个复杂的模型多样化，还涉及到这些特征是否经过业务活动以后的特征，比较复杂，至于如何表达Product和某个Part之间的这种非高聚合，而是一种非常松耦合的关系，可以专门设立一个Node或Key-value对来表达它们之间的关系，比如Key为888, Value为Part的Id。

我比较认同文中一种隐式观点，那就是，只有需要事务时才需要RDBMS，而且这种事务还不是高频的，否则又不合算了。

也就是说，RDBMS的核心竞争力只是它的ACID事务而已，可靠性，其他都可以被替代。只是可能我们太过重依赖它，以至于发现没有它好像什么都不行，其实这是一种习惯培养的错觉。另外，我觉得也只有试图去除RDBMS，我们才能真正发现软件表达业务的价值，就像孩子必须离开父母才能找到自己的价值一样。

[该贴被banq于2012-11-25 17:23修改过]

如果核心竞争力是事务，其他类型数据库早早晚晚都会赶上的，RDBMS核心竞争力应该是其“简洁”的存储结构，假设存在一个工具可能让其数据与其他非关系数据库相互转化，非关系数据库的数据绝对转化并存储到关系数据库上，而关系数据库的数据并不一定能转化并存储其他非关系数据库