我们正在尝试在我当前的项目中使用 DDD 技术，并且已经开始经历域建模的过程，并且在“如何”创建域模型方面遇到了很多摩擦。我还没有找到很多我们在这个主题上的指导的例子。
我们首先尝试通过与业务用户交谈并提出域实体及其属性列表来定义通用语言。进展顺利，但我们遇到了以下问题：
我对如何捕捉所有这些不同的东西（序列图、用例、流程图等）有很多想法，但如果有一个正式的流程或一些资源提供示例驱动的指导，它肯定会加快速度事情好了一点。
这是一个很好的问题。
我总是采取的第一步是与一位（是的）领域专家会面，并从他们的角度就问题领域进行公开讨论。我带了很多便利贴，并确保我有足够的白板空间。正如专家所说，我尝试使用便利贴在墙上绘制流程图或 BPMN 图。我发现给领域专家一些视觉上的东西是非常重要的——他/她可以用身体指向并说“不，那是错误的！” （他们通常会做很多次）。
在这些对话中，我正在仔细聆听专家所说的内容，并要求澄清存在歧义的地方。我总是发现让无处不在的语言以这种方式自然出现更好——而不是试图强行建立它（我永远不会要求领域专家给我一份术语列表）。
我尝试用命令和事件来表达流程图——即使我最终没有使用 CQRS，我发现这自然会流入更具体的需求。当流程图完成时（我通常可以这么说，因为专家看起来对此非常满意——很有可能他/她从未见过以这种方式绘制的域，而且他们常常对新奇感到兴奋），我开始通过流程图跟踪各个路线。通常，这些单独的路线可以很容易地表达为Given, When, Then风格要求方面的行为规范。（见BDD第 3 节）
一旦你有一个集合Given, When, Thens涵盖了流程图中的每条路线，你就有足够的规范来开始一个领域模型的设计阶段Bounded Context。
我与其他领域专家重复这个过程。与后来的专家一起，我还倾听他们使用的语言和术语之间的相关性。大多数时候，不同的领域专家会使用通用语言共享术语，但含义会略有不同。这表明我们正在处理不同的有界上下文。