创建概念域模型的方法

时间:2013-07-16 13:54:08

标签: domain-driven-design

我们正在尝试在我当前的项目中使用DDD技术并开始经历域建模过程,并且围绕“如何”创建域模型遇到很多摩擦。我没有找到很多关于这个主题的指导。

我们首先尝试通过与业务用户交谈并提出域实体及其属性列表来定义泛在语言。这很顺利,但我们遇到的问题包括:

  • 行为,行动
  • 权限
  • 业务逻辑(如果attributeA = true,则foo else bar)

我对如何捕获所有这些不同的东西(序列图,用例,流程图等等)有很多想法,但如果有正式的流程或某些资源提供示例驱动的指导它' d肯定能加快速度。

1 个答案:

答案 0 :(得分:5)

这是一个很好的问题。

我一直采取的第一步是与一位(是的)领域专家会面,并从他们的角度对问题领域进行公开讨论。我带来了大量的便利贴,确保我有足够的白板空间。正如专家所说,我尝试使用post-it在墙上绘制流程或BPMN图。我发现给领域专家提供一些可视化的东西是非常重要的 - 他/她可以在物理上指出并说“不,那是错的!” (他们通常做很多次)。

在这些谈话中,我正在仔细聆听专家的意见,并要求澄清哪里有歧义。我总是发现最好让无处不在的语言以这种方式自然地出现 - 而不是试图强有力地建立它(我永远不会要求领域专家给我一个术语列表)。

我尝试用命令和事件来表达流程图 - 即使我最终没有使用CQRS,我发现这自然会流入更具体的要求。当流程图完成时(我通常可以告诉这一点,因为专家看起来非常满意 - 他/她很可能从未见过以这种方式绘制的域,并且他们常常被新奇感到激动),我开始通过流程图跟踪单个路线。通常,这些单独的路线可以根据Given, When, Then样式要求轻松表达为行为规范。 (见BDD第3节)

一旦你有一个涵盖流程图中每条路线的Given, When, Thens集合,你就有足够的规范来在一个Bounded Context中开始一个域模型的设计阶段。

我与其他领域专家重复此过程。随后的专家我也会听取他们使用的语言和术语之间的相关性。大多数情况下,不同的领域专家会分享无处不在的语言,但意味着略有不同。这表明我们正在处理不同的有界上下文。