Rya*_*ice 3 domain-driven-design
我们正在尝试在我当前的项目中使用DDD技术,并开始经历域建模过程,并且在"如何"创建域模型方面经历了很多摩擦.我没有找到很多关于这个主题的指导的例子.
我们首先尝试通过与业务用户交谈并提出域实体及其属性的列表来定义无所不在的语言.这很顺利,但我们遇到的问题包括:
关于如何捕获所有这些不同的东西(序列图,用例,流程图等等),我有很多想法,但如果有正式的流程或一些资源提供示例驱动的指导,它肯定会加速事情好一点.
这是一个很好的问题.
我一直采取的第一步是与一位(是的)领域专家会面,并从他们的角度对问题领域进行公开讨论.我带来了大量的便利贴,确保我有足够的白板空间.正如专家所说,我尝试使用post-it在墙上绘制流程图或BPMN图.我发现给领域专家提供一些可视化的东西是非常重要的 - 他/她可以在身体上指出并说"不,那是错的!" (他们通常做很多次).
在这些谈话中,我正在密切倾听专家的意见,并要求澄清哪里有歧义.我总是发现让无处不在的语言以这种方式自然地出现更好 - 而不是试图强行建立它(我永远不会要求领域专家给我一个术语列表).
我尝试用命令和事件来表达流程图 - 即使我最终没有使用CQRS,我发现这自然会流入更具体的要求.当流程图是完整的(我通常可以说,是因为专家看起来很欣慰吧-有他/她从来没有见过的域名映射出这种方式,他们常常被新奇兴奋的好机会),从我做起通过流程图跟踪单个路线.通常,这些单独的路线可以根据Given, When, Then样式要求容易地表达为行为规范.(见BDD第3节)
一旦您的集合Given, When, Thens涵盖了流程图中的每条路径,您就有足够的规范来完成一个域模型的设计阶段Bounded Context.
我和其他领域专家重复这个过程.随后的专家我也会听取他们使用的语言和术语之间的相关性.大多数情况下,不同的领域专家会分享无处不在的语言,但意味着略有不同.这表明我们正在处理不同的有界上下文.