别把领域驱动开发给用错了

  • Jan Stenberg
  • 夏雪

2015 年 4 月 28 日

话题:架构语言 & 开发

通常,有很多的应用声称是用领域驱动开发(DDD)构建出来的,并且有一个领域模型,但是这个模型实际上却仅仅包含业务实体,甚至于分离数据和逻辑的数据传输对象和服务都混合在了一起,其中也分不清业务和基础设施逻辑,Gabriel Schenker 分享了从事咨询和软件架构以来的个人经验。在具有消息处理的应用中,很少用业务领域中名称来命名消息,反而采用了以updatemodify结尾的这种统称。

Schenker 目前是一位首席软件架构师,他说这一点儿都不夸张,他本人就常常发现早期的新应用就是这么构建出来的。Schenker 认为,这一现象的主要原因就是由于缺乏知识。

Schenker 强调说,如果采用 DDD 开展工作可以参考 Eric Evan 的DDD 专著,但其中的所有模式的重要程度并不是安全相同的,特别是要注意这本书中后面部分的 DDD 基础,有些已经得到了 Evans 的充分肯定。与这些策略模式形成鲜明的对比的是,上半部分中的战术模式重点关注于实现的细节。

Schenker 建议说,当使用 DDD 开始一个新项目时,首先应和领域专家对业务领域达成一致的理解,把讨论中的术语抽取出来,大家共同商定创建一个通用的词汇表,在 DDD 术语中这叫做统一语言。让领域专家识别彼此间分离的区域,把复杂的领域予以分解,从而创建子领域或有边界的上下文,嘿嘿,这又是另一个 DDD 术语。

Schenker 还告诫说,不要以数据模型开始创建一个以数据为中心的世界。他坚信,孤立的数据什么都不是,数据若想有意义就离不开逻辑,而且还要注意上下文的变化,所以,上下文和逻辑应该是 DDD 的主要关注点。专注于数据还有另一个风险,数据库最终会用于集成,实际上这从另一方面增加了上下文间的依赖。Stefan Tilkov 也于近期建议避免采用通用的数据模型。

查看英文原文:Domain-Driven Design the Wrong Way

架构语言 & 开发