ORM真的不适合DDD

13-10-08 daxnet
第一篇帖子,先自我介绍一下,我从07年开始关注并实践DDD,也一直在关注jdon的成长(虽然一直没有注册ID并发言)。自己的tech stack是.NET阵营的,一致也在致力推广.NET下DDD的实践。但设计和架构上的思想基本还是一致的。
最近在思考一些ORM和DDD的问题,但是不知道我的思路是否正确。还请banq以及各位大师指点。
问题来自一个非常简单的建模:文章(Article)、类别(Category)。根据当前的应用场景,从聚合划分上看,简单地说,“文章”、“类别”都属于聚合根,由于类别不是文章应具备的一个属性(因为文章本身不会因为没有被归到某个类别而不成其为文章),反之亦然,所以它们之间互相是没有引用的。
稍作分析,可以发现,其实在这个例子中,还有一个隐藏的聚合,称之为“分类(categorization)”,它是对文章与类别之间关系的描述,当然,这个“分类”也无法聚合“文章”和“类别”,因为“文章”、“类别”两者与“分类”的生命周期是不同的,因此只能通过ID关联。于是,模型大致如下(抱歉是C的代码):

public class Article
{
    public virtual Guid ID { get; set; }
    public virtual string Title { get; set; }
    public virtual string Content { get; set; }
}

public class Category
{
    public virtual Guid ID { get; set; }
    public virtual string Name { get; set; }
}

public class Categorization
{
    public virtual Guid ID { get; set; }
    public virtual Guid CategoryID { get; set; }
    public virtual Guid ArticleID { get; set; }
}
<p class="indent">


在得到了上面的假设之后,我开始使用NHibernate(Java阵营是Hibernate)试图完成对上述模型的持久化。根据DDD,Repository管理聚合生命周期,Repository模式的引入,让Domain Model能够独立于持久化机制(ORM或者其它),从而剥离出一个非常纯净的Domain Model。于是,结合NHibernate,我原以为实现一个基于NHibernate的Repository,就能将聚合直接由Repository转交给NHibernate,从而使用NHibernate这一ORM产品来实现对象生命周期管理。

不幸的是,我发现我无法在NHibernate中配置用于上述Model的映射方案:Categorization.CategoryID属性是关联到Category.ID的(从数据库角度看,就是一个外键关联),然而要在NHibernate中正确地配置外键关联,就必须要求两个对象之间有一对一、一对多等等属性引用。但一开始我们就分析了:在我们的Domain Model中,Category和Categorization之间、Article和Categorization是无法直接引用的(领域建模不允许这么做)。

于是,我就意识到,DDD社区中所谓的Impedance Mismatch,并不是说Domain Model与关系型数据库之间的Mismatch,而是Domain Model与整套关系模型之间的Mismatch。因此,要解决这里的问题,我们还需要有一层面向NHibernate ORM的对象关系模型(即持久化模型),并在Repository中将Domain Model转换为持久化模型,然后再使用NHibernate。

总结起来,这个过程就是:
Domain Model -> Repository -> (translate to) Persistance Model -> ORM (eg. NHibernate)
换句话说,相对于其它对象数据库和NoSQL而言,ORM无法很好地支持DDD,还需要有一层从Domain Model到Persistance Model的映射。

不知我的理解是否正确。恳请指点。

[该贴被admin于2014-03-09 07:44修改过]

15
w438418754
2013-10-08 14:10
有关系的,Categorization与Article(或Category) 是多对一的关系,

daxnet
2013-10-08 16:00
对,我们的理解是有关系的,然而正如我上面的分析,在Domain Model确定这些聚合的时候,情况却不一样。

px96004
2013-10-08 16:37
不太理解啊...既然要求

Category和Categorization之间、Article和Categorization是无法直接引用的(领域建模不允许这么做)

那就不引用了呗...
在hibernate里面不设置 一对一,一对多之类的关系呗...

不就行了么?

daxnet
2013-10-08 17:31
当然可以不设置,但在自动产生ID值的时候会存在问题,比如如果使用guid generator,那么当我们创建一个Article的时候,如果同时希望能够将它归类到一个类别中,于是就需要在同一个事物中同时更新categorization,但这时候事实上Article的ID没有生成。
虽然可以使用assigned的方式,由构造函数自己产生ID,但这种做法还是有些不自然。

gameboyLV
2013-10-08 21:40
//领域对象
public class Contact
{
  public string ContactName { get;set;}
  public AddressDTO Address { get;set;}
}
public class AddressDTO
{
  public string Country { get;set;}
  public string Province { get;set;}
  public string Street { get;set;}
}
<p class="indent">

//数据库对象
public class AddressInfo
{
  public Guid ID { get;set;}
  public Guid ContactID { get;set;}
  public string Country { get;set;}
  public string Province {get;set;}
  public string Street { get;set;}
}
<p class="indent">

不管你用不用ORM,从数据库对象到领域对象都必须手工编码转换。AddressDTO类可能并不在领域层,而是在横切层,用于数据传输。

一行DataRow是无法表达任何信息的,而领域对象中包含的数据传输对象则可以表达明确的含义。那么将DataRow转换为DTO的工作由谁来完成呢?我认为可以放在横切层。

Repository 发出消息请求加载数据,消息转递到横切层后,横切层分析消息并将消息拆分为若干个子消息,转发给持久层。数据加载完毕之后,横切层分析数据库中加载过来的数据是否合法,如果合法,则返回DTO集合。

这样处理又带来了新的问题,AddressDTO和AddressInfo有类似的字段,能否重用呢?当然不行。。。。但是我们可以使用动态编译技术,在程序集加载时自动检索数据库,并生成强类型的AddressInfo。这样一来,持久层就被我们藏起来了,程序不用手工操作ORM。

        public static Assembly Compile(string filePath, string modelDefinition)
        {
            CompilerParameters objCompilerParameters = new CompilerParameters();
            objCompilerParameters.ReferencedAssemblies.Add("mscorlib.dll");
            objCompilerParameters.ReferencedAssemblies.Add("System.dll");
            objCompilerParameters.OutputAssembly = filePath;
            objCompilerParameters.CompilerOptions = "/target:library /optimize";
            objCompilerParameters.IncludeDebugInformation = false;
            objCompilerParameters.GenerateExecutable = false;
            objCompilerParameters.GenerateInMemory = true;

            CSharpCodeProvider objCSharpCodePrivoder = new CSharpCodeProvider(new Dictionary<string, string>
            {
                { "CompilerVersion", "v3.5" }
            });
            CompilerResults cr = objCSharpCodePrivoder.CompileAssemblyFromSource(objCompilerParameters, modelDefinition);
            if (!cr.Errors.HasErrors)
            {
                Assembly objAssembly = cr.CompiledAssembly;
                return objAssembly;
            }
            return null;
        }
<p class="indent">

daxnet
2013-10-08 22:32
2013-10-08 21:40 "@gameboyLV
"的内容
不管你用不用ORM,从数据库对象到领域对象都必须手工编码转换。 ...


理论上的确是这样的,正如我在本帖正文中所述,Persistance Model(PM)和Domain Model(DM)是不同的。

Repository的职责就是管理聚合的生命周期,所以Repository的操作对象就是聚合(当然是通过聚合根来将关联对象一并处理,因为这些对象的生命周期相同)。在实践中,是否需要将DM转换为PM,我觉得还是跟选取的持久化技术有关。如果使用ORM,Impedance Mismatch效应就比较明显,因此有必要进行DM/PM转换,但如果是OODB,或者NoSQL等其它解决方案,或许直接存取整个聚合就变得非常直接自然,此时DM直接作为PM也未尝不可。

这就有点像Domain Model和View Model之间的差异一样:VM专注于表示层,其结构和关联关系由表示层决定,因此DM不能直接用作VM,但在某些情况下,或许DM的结构正好能够适应表示层的数据展示,那么将DM用作VM也不会有太大问题。

我发这个帖子的主要目的就是阐述了我的一种感受,并希望能够验证这样的想法:在实践中让我觉得,ORM的Impedance Mismatch使其相较于其它持久化技术而言,不太适合DDD实践。

tangxuehua
2013-10-09 19:15
如果楼主所说的Article, Category是指博客系统中的文章和分类的话,那我觉得首先:它们是独立的聚合根,但是我觉得没必要设计Categorization这个聚合根了。
1. 因为在业务上,我们没有明确的场景会创建Categorization聚合根,这个聚合根对用户来说是没意义的,感知不到的。
2.聚合根一个很重要的职责就是对规则建模。这里的Categorization我看不出内聚了什么规则,这个聚合只是说明了文章和分类之间有某种关系,但具体是什么关系不得而知,比如是1:1,还是1:N,还是M:N呢?其实都有可能。所以这个聚合实际上业务含义很模糊。
3.Article,Category之间,从业务上来说,category是不关心article,所以category不必存放关于article的任何信息,这点没问题;但是article我们在新建或修改时,都会关心当前article属于哪个分类(比如博客园里我们发表文章的时候就要选择所属分类,可以选择多个)。所以,我觉得很明显,在这种业务场景下,article需要关联一些category,但是为了聚合边界之间的清晰,我们只用ID关联,所以就可以设计一个IList<CategoryId>这样的值对象属性categoryIds在article上即可。这个categoryIds属性表达了当前文章和哪些分类关联。同时还包含了一个潜在的业务规则,就是一个文章不能关联两个相同的category。这个业务规则如果用Categorization是没办法在聚合层面做到的。这里categoryIds这个属性是完全内聚在article这个聚合内的,和category无任何关系了。因为categoryId只是一个值对象。
4.如果设计出Categorization这个聚合根,那就意味着创建文章的时候,会同时创建Categorization这个聚合根,这就导致一个command同时修改了两个聚合,这已经违背了“一个命令影响一个聚合”的原则。此时我们就得想想是否聚合设计的有问题了。

daxnet
2013-10-10 07:57
非常不错,雪华说得很有道理,之前在设计这个聚合模型的时候,我就遇到了这样的困惑,经过你的指点,我觉得你的设计更为合理,更切合DDD的本意。
另外对于ORM是否适合DDD的问题,我想,虽然我的例子举得有点问题,但是还是能从侧面反映ORM的这个问题的。简单地说,用于ORM机制的存储模型与领域模型应该是两个完全不同的概念。虽然仓储应该直接对聚合进行管理,但在仓储的具体实现中,就不一定能够直接将聚合一股脑塞给持久化机制(如果是使用OODB的话,或许也可以)。

banq
2013-10-10 16:34
2013-10-10 07:57 "@daxnet
"的内容
对于ORM是否适合DDD的问题 ...


DDD和CQRS是一对姐妹,DDD易于理解,但难以解释实现,而CQRS易于解释实现,但难于理解,两者结合就很自然。

在CQRS架构中,我们甚至只使用数据库来保存导致状态变化的事件,这样通过eventSourcing来保证聚合内部状态变化的一致性,根本不使用数据库来保存状态,这样完全杜绝数据库用来持久化聚合对象的用法,ORM等工具毫无用处之地。

参考:

http://www.jdon.com/45796

daxnet
2013-10-10 17:06
不错,从CQRS的角度考虑这个问题,就会更加清楚。事实上最终需要保存的就是这些事件,这样不仅让数据库结构变得非常简单(或许只有1张数据表就能实现),大大提高了效率,甚至还可以不使用数据库产品来实现事件的存储。或许我不应该从我所描述的这个案例中去理解这个问题。

tangxuehua
2013-10-10 17:50
恩,CQRS架构下,command端不需要使用数据库了,所有聚合根是in-memory的,用redis等nosql存储即可;eventstore里所有事件的结构都一致,且永远只有append,所以非常适合用nosql来实现。

我现在的框架中,eventstore用mongodb,redis都有实现;in-memory,目前使用redis来实现;

in-memory挂掉,则因为redis支持持久化,重启后就能恢复in-memory的数据,就算丢失一部分数据,也能根据eventstore恢复。

而eventstore,因为不能丢数据,虽然也是用redis,但是要利用redis的aof的方式来确保事件都会持久化,aof刷盘的频率是1s,这样可以基本确保数据不会丢失。如果要绝对不会丢失,我觉得现在的服务器都有UPS电源,服务器掉电后,至少应该能坚持1s吧,呵呵,所以坚持到日志都刷入到磁盘肯定没问题了。所以我不担心数据丢失的问题。说句题外话,目前的nosql产品,为了高性能,都是用日志append的方式顺序写入cmd,然后系统恢复的时候,读取日志,然后重新执行这些cmd。这个过程是不是和event sourcing很像啊,呵呵。只不过人家是用command sourcing啦,哈哈。

这样的方式,由于redis的单实例性能就非常突出,单个redis实例的写入性能,官方测试结果是11W次每秒,读取时8W次每秒。所以整个架构可以说性能非常之高。

如果担心单个redis放不下所有数据,那可以通过sharding(因为redis服务端本身不支持sharding)的方式,将不同的业务数据的事件放到不同的redis实例内。也就是我们需要提前做好容量规划。同时,in-memory也是一样要做好规划。

另外,如果要更可靠点,那需要做replication了。目前redis只支持master-slave模式,不支持master-master模式,这方面有点薄弱,但redis的作者提供了一个presharding的方案,个人认为还是靠谱的,可以简单的做到在线扩容,具体大家可以再去查一下。

至于CQRS的查询端,我目前还是使用普通的关系型数据库,反正数据更新时异步的嘛,慢慢更新好了。如果用户希望能实时看到一些数据,那我们在查询端也可以设计一些缓存,通过event handler更新缓存,对查询延迟要求高的系统,可以走缓存。不高的场景,走mysql就行了。

最后一点就是消息队列,目前最新的思路是想用:zeromq+redis,zeromq性能高的离谱,但是无持久化,而持久化就用redis来做,感觉应该可行;我不需要非要强大的消息队列,只要支持我所需要的场景即可;RabbitMQ这种虽然强大稳定,但是效率和zeromq比起来,不是一个数量级的;在cqrs+event sourcing+in memory这样的架构面前,性能我觉得是第一位的,呵呵。关于消息队列,淘宝有一个开源的metaq,发现性能也不错,功能很强大,是分布式的,目前没有.net的客户端,但只要有java的客户端,那自己写一个.net的客户端也问题不大;性能测试报告见:http://alibaba.github.io/metaq/document/benchmark/benchmark.htm

最近正在晚上和打算进行测试这个架构。

[该贴被tangxuehua于2013-10-10 18:08修改过]

[该贴被tangxuehua于2013-10-10 18:15修改过]

w438418754
2013-10-11 09:18
而eventstore,因为不能丢数据,虽然也是用redis,但是要利用redis的aof的方式来确保事件都会持久化,aof刷盘的频率是1s,这样可以基本确保数据不会丢失。如果要绝对不会丢失,我觉得现在的服务器都有UPS电源,服务器掉电后,至少应该能坚持1s吧


我觉得你这样考虑有些问题,假设数据量非常大,redis在1s中无法全部保存呢,那么你的数据必然丢失
而且command端中的in-memory 需不需要用到redis也是个疑问,in-memory中的domain model 根本就没有分布式的意义

tangxuehua
2013-10-11 09:54
也许整个系统的数据量产生非常快,如果真是这样,那我们可以水平分割数据呀。如果全部写到一个redis实例,redis来不及持久化,那就应该sharding,也就是把数据分片,不同的数据写到不同的redis实例中,这样每个redis实例的写入请求不会太高。
磁盘的append速度是非常快的,1s内可以刷很多数据的。另外,对于这种存储的服务器,我们还可以用ssd提高写入速度。

对于domain in-memory采用分布式的意义是,可以让应用服务器不存放任何domain数据,分布式的方式来存放domain in-memory的意义是数据被所有应用服务器共享。这样就能让应用服务器可以随便挂,反正无状态。

w438418754
2013-10-11 12:09
才用分片的情况下确实能解决非常大的数据量的问题,但是还是存储保存不及时的情况下死机,断电等情况

才用分片的情况下,对于redis也没什么作用,同一条数据不可能被两个应用服务器使用的,如果出现这种情况,就会产生并发问题

猜你喜欢
4Go 1 2 3 4 下一页