与DDD领域专家共事

在2016年年初举行的领域驱动设计欧洲大会上,Cyrille Martraire在演讲中分享了他在DDD驱动的环境中与领域专家共事的经验。他指出,在领域驱动设计中,与领域专家对话及所使用的语言是关键,这通常会因为所说的语言不同而出现困难。

Martraire是“巴黎软件工艺社区(Paris Software Craftsmanship Community)”的创始人,同时也是arolla的联合创始人。他指出,要想与领域专家成功地对话,首先需要自学一些领域知识。做好功课,提前准备一些知识,例如读书或在互联网上查找信息。

在Martraire看来,展示一些领域知识是一种和专家建立信任及改善沟通的方式。以下是三种简单的方式:

显得你真的很好奇,并展示你的知识; 提出更好的问题,并随着对话进行改进它们; 挑战,但要恭敬。
Martraire指出密切注意词汇避免转换或其他曲解的重要性。他特别提到,积极聆听非常困难,所以他创建了一种他称之为Word Safari的技术,从中他可以标记出所有出自领域专家之口的新词。然后,他就可以检查下它们是新概念还是同义词。他强调,这不仅仅是一个简单的技巧——注意DDD中使用的语言至关重要。

Martraire发现,“引导对话(navigating the conversation)”是一项实用的技术。你可以将对话向上引导,引向一个更抽象的层次,总结并发现意图。这里的关键问题是“为什么”,通常要问多次。你还可以将对话向下引导,引向更具体的细节,这时,示例成了发现误解的一个重要手段。使用示例的一种方式是使用行为驱动开发(BDD)和专家一起描述具体的行为示例。第三种引导对话的方法是偏离对话主线,拓宽领域。有时候,这可以揭示出根本就没讨论到的环节。

让领域专家清楚地认识到,与你对话很安全,你没有计划窃取他们的工作,Martraire认为这是一条特别重要的原则。这样做的一个结果是你什么东西都要求验证;最终,你和领域专家就领域达成共识。

这一切看上去很美好,也很简单,但根据Martraire的经验,有时候很难找到一位优秀的领域专家。他指出:

最差的领域专家是那些专业知识来自错综复杂的现有系统的专家。

同时,他还指出,他的经验可能有点片面,因为他通常是根据DDD潜力以及相关人员的整体心态选择项目。

本文转自d1net(转载)

时间: 2024-09-12 16:01:20

与DDD领域专家共事的相关文章

危险的DDD聚合根

DDD的核心是聚合.这没有问题,大家都认同.但关于DDD中的聚合方式,其实我还是有些担心,下面说说我的想法,希望大家参与讨论. 其实当初第一次看到DDD中关于聚合根部分论述的时候,就感觉有些僵化.DDD中的聚合根的分析设计思路大致是这样:1.业务本质逻辑分析:2.确认聚合对象间的组成关系:3.所有的读写必须沿着这些固有的路径进行. 这是一种静态聚合的设计思路.理论上讲,似乎没有什么问题.但实际上,人对第一步中的业务逻辑分析就是一个渐进的过程,不是稳定不变的.不是谁都可以成为业务领域专家,就算是业

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型: 由领域模型驱动软件设计,用代码来实现该领域模型

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

领域驱动设计(DDD)部分核心概念的个人理解

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家

领域驱动设计(DDD)部分核心概念的个人理解(转)

  领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域

从事件和DDD入手来构建微服务

领域驱动设计(Domain-Driven Design,DDD)是一项很伟大的技术,它拉近了设计与程序实际所服务的领域,但是通常我们会关注结构,从而太早地做出决策,这并非DDD的本意.相反,在领域中,我们应该从事件开始,Russ Miles描述了在构建微服务时,采用"事件优先"的方式所具有的优势. Miles认为除了关注结构之外,我们还过多地关注了通用语言(ubiquitous language),尤其是在领域对象方面更是如此.更糟糕的是,我们还会着手创建一些跨领域边界重用的库,这些库

DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考

之前,在用ENode开发forum案例时,遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题.后来找到了自己认为比较合理的解决方案,分享给大家.也希望能和大家交流,擦出更多的火花. 论坛核心领域问题分析 论坛领域的核心概念是:帖子.回复.大家都知道,一个帖子可以有零个或多个回复.对同一个帖子,不同的人可以并行发表回复.回复发表后,查看帖子详情时,可以根据回复的发表时间排序显示:此外,我们还关心某个帖子的最新发表的回复.最新回复的作者.最新回复时间,以及总回复数. 我们设计的系统,应该在实现

DDD领域驱动设计:领域服务

什么是领域服务,DDD书中是说,有些类或者方法,放实体A也不好,放实体B也不好,因为很可能会涉及多个实体或者聚合的交互(也可能是多个相同类型的实体),此时就应该吧这些代码放到领域服务中,领域服务其实就跟传统三层的BLL很相似,只有方法没有属性,也就没有状态,而且最好是用动词命名,service为后缀,但是真正到了实践的时候,很多时候是很难区分是领域实体本身实现还是用领域服务区实现的,除了那些需要操作(一般是参数了)多个实体的方法外,有些单个实体的操作是很难严格区分的,实际上放实体和领域服务都可以

DDD领域驱动设计:领域基础设施层

其实这里说的基础设施层只是领域层的一些接口和基类而已,没有其他的如日子工具等代码,仅仅是为了说明领域层的一些基础问题 1.领域事件简单实现代码,都是来至ASP.NET设计模式书中的代码 namespace DDD.Infrastructure.Domain.Events { public interface IDomainEvent { } } namespace DDD.Infrastructure.Domain.Events { public interface IDomainEventHa