Eric Evans关于技术如何影响DDD的会话

12-09-13 banq
                   

infoQ播放了DDD的创建者Eric Evans最新录像,谈了关于如今新技术对DDD的影响:Eric Evans on How Technology Influences DDD

我个人印象比较深入的是下面四点:

1.NoSQL和关系数据库一样,只是对象的一种持久方式。

关系数据库是最伟大的发明之一,关系模型也是看待问题最强大的工具,而面向对象也是一种看待问题的强大工具,但是如果你将两者捆绑在一起,实际是损毁它们的优点。

对象概念其实很长时间已经被J2EE等重量框架摧残了很长时间,而且更被阴险的映射到关系数据库上。

2.Domain Events或Event Sourcing实际是从面向函数角度去思考,面向函数语言的思维方式是一种流思考方式。值对象在面向函数中很自然,实际就是数据结构。

3.领域对象应该生存在内存中, 如果我们有一个巨大的内存存储,对象就能够成功生存,但是当你和关系数据库进行绑定等,你就会遭遇彼此的不匹配,如果你要得到快速的,好的 非常嫩脆的对象,就应该将他们放入内存中。

4.DDD最大特点是统一语言。

[该贴被banq于2012-09-13 16:18修改过]

                   

7
banq
2012-09-14 15:25

个人想法:

这几天AAOSConf 真正召开,DDD和CQRS成为热门。

关于对象和关系数据库阻抗,本站一直在讨论,我在使用DDD开发Jivejdon开始时就坚持使用SQL,而当时ORM框架包括Hibernate很火,我也不是出于远见,而是让领域模型更加简单些,不要被ORM等配置给牵涉。如今大家都已经承认Hibernate代表的那段适合火红的岁月其实是一场越战。

Martin Fowler厌倦ORM了

对象应该生存在内存中,这是我当初开发JdonFramework的基本特点之一。

DDD最大特点是统一语言,统一语言其实也是统一思想,比如敏捷方法行为驱动开发BDD也是一种统一语言:行为驱动开发(BDD)如何与领域驱动设计(DDD)结合?,我觉得它的Given When Then模板非常实用,能够分解复杂的业务场景。

最近也讨论了:业务模型统一描述,我个人使用三个元素来表达统一语言:场景 事件和状态。

这三个元素每个后面都有一段隐式的定义:

场景:Context,可以理解为DDD的bounded context,也可以理解为DCI的Context,也对应于用例的Context,属于BDD中的Given。从逻辑上说,这是一段“假设”。

事件:表达对象之间交互的行为,对应于DCI的交互,也可以认为是BDD的When。我在业务建模:上下文(场景)还是服务?中提到,对象行为分为两种,一种是维护内部状态,一种是对外交互。前者通过DDD的聚合根这个结构角色确定下来;后者通过DCI中角色确定下来,虽然这两种行为分离,实际上是区分了不变和可变,可变的对外交互和场景角色有关,隔离了对实体对象的影响。

在这篇Event Sourcing + DDD带来的模型重构问题如何解决?,我认为正是忽视了这种分离,才导致实体的重构会影响交互性质的事件。

状态:状态和对象的内部行为有关,也是由DDD聚合根这个角色实施,如果实体之间没有从属关系,各自对自己负责,它们就可以称为聚合根。

状态是实体的状态,表达了实体参与了各种场景业务以后的结果。如果我们要还原某个业务场景发生前的状态和发生后的状态,只有实体状态是无法做到的,实体状态只能表达当前最新状态,历史状态基本不会记录,如果记录历史状态,不如记录历史事件更加精简,这样的事件可以实现重放和回放,这也是Event Sourcing意义所在。

总之:通过场景 事件和状态这三个关键词,我们可以抓住需求到架构代码实现的主要脉络,不至于错误表达需求,也不会无法灵活跟随需求,更不会因为代码自身重构带来架构变动。因为我们已经确定了建筑的钢架结构。

当然,实践中最难的是分辨出哪些是场景 哪些是对象的对外交互行为,哪些是维护状态的内部行为。

tangxuehua
2012-09-15 00:54

理论很丰富,但我觉得都只是点到即止,很难让人印象深刻或信服。个人认为还是拿些实际例子出来分析来的靠谱。

另外,我的帖子“Event Sourcing + DDD带来的模型重构问题如何解决”所表达的意思和你理解的不是一个意思。要知道有时虽然一个对象的结构没有变,但它的重要性或独立性可能会变化。比如同一个实体,之前是实体,后来我认为它应该独立,于是把它升级为聚合根,但是其结构完全没变化;另外,按照你的理解,聚合根用于维护内部状态,比较稳定,属于不变的部分,这个不认同,我们的聚合根为什么不会变?是因为只表示数据结构吗?谁说数据本身的结构或数据之间的结构不会变化?实际上很多变化都属于这类变化。也就是说,你说的用于维护内部状态的聚合根或实体的立场/独立性,或结构本身,或它们之间的关系都会变化,这种变化与如何与外界交互无关,即与Context无关,属于内在本质属性或内部对象结构的变化。

[该贴被tangxuehua于2012-09-15 01:07修改过]

banq
2012-09-15 07:02

2012-09-15 00:54 "@tangxuehua"的内容
这种变化与如何与外界交互无关,即与Context无关,属于内在本质属性或内部对象结构的变化。 ...

这个我很认同,如果你的需求经常变,那么直接映射需求领域中的领域模型,也就是实体内部属性会经常变化。还有一个情况,如果你的领域模型无法真正反映领域中本质,提炼得“中看不中用”(DDD书中语),那么领域模型当然也会变。

但是,如果我们的领域模型反映了需求,而且项目趋于结束,以我开发的jivejdon论坛为案例吧,已经五六年了,其ForumMessage和ForumThread之间结构很少变(不会发生今天ForumMessage映射到Forum,明天又改为和ForumThread,这种关系不怎么变。),当然ForumMessage的字段有增加修改,这不会影响大结构的数据字段变化是正常的。

虽然你是搞微软,但是有空可以参考一下Jdonframework,使用Jdonframework开发DDD+DCI+Domain Events真的很方便,完全是从领域模型角度出发的,而现有J2EE标准框架或Spring+Hibernate真的不适合DDD的开发,而估计微软世界和J2EE差不多。

clonalman
2012-09-15 07:44

2012-09-15 07:02 "@banq"的内容
Events真的很方便,完全是从领域模型角度出发的,而现有J2EE标准框架或Spring+Hibernate真的不适合DDD的开发,而估计微软世界和J2EE差不多。 ...

看来在对DDD的认识上还是有本质的区别,唯一能禁锢思想的是思想本身

5Go 1 2 3 4 ... 5 下一页