发一个自己设计的KylinORM，另有疑惑

不知道大家有没有这样的疑惑，在项目中使用DDD时，领域对象有时候需要调用BO，BO有时候为了实现特殊的数据库操作，又需要跨过Repository直接操作领域对象。

本来负责逻辑运算的BO是不应该和领域对象打交道的，比如将人民币转换成美元，个人感觉是应该放在服务层里面的。

在两个项目中应用DDD之后的结果就是，逻辑BO、事务BO、领域对象、基础架构都混杂在一起，维护不便。而且用了大量自动生成的代码来维护OR映射和领域关系，还有一些的XML和[Attribute]标识的配置文件。

虽然有一些其他的方案能解决上面的问题，比如PURE MVC的消息模式。但是。。。把大部分精力消耗在基础架构上实在不值得，于是就有了现在的KylinORM。

这是一个使用TAG网络来维护实体关系的ORM框架。
[该贴被gameboyLV于2012-03-10 09:56修改过]
attachment:

2012年03月10日 09:53 "@gameboyLV"的内容

逻辑BO、事务BO、领域对象 ...

有一个疑惑，你这里逻辑BO和领域对象有什么区别？如果业务逻辑都跑进了BO，领域对象是一个贫血模型吗？

在我的思路中：领域对象是负责做什么等战略目标，就像国家政策很宏观，而每个目标的怎么做问题才是一些BO核心，按照这个逻辑，应该是领域对象指挥BO，就象司令官指挥军队一样，我看你的设计意图是让BO指挥领域对象，所以有些疑惑。
[该贴被banq于2012-03-10 10:06修改过]

2012年03月10日 10:00 "@banq"的内容

逻辑BO和领域对象有什么区别 ...

我的逻辑BO就是不需要和数据库交互的BO，纯粹数据方面的计算，比如数据挖掘（从内存/缓存中读取数据，然后统计）。

和数据库事务相关的BO我还是放在领域对象中的，比如发帖子。

理解，类似一种领域服务，但不是基于对象，而是离散的数据。这个框架思路挺好，支持一下。