基于用户故事的领域驱动DDD

用户故事

什么是用户故事及如何描述

在软件开发中，用户故事是一种对软件系统特性的非正式的自然语言描述，是敏捷软件开发中从终端用户的角度对软件系统寺性进行捕捉的一种方式。用户故事描述了不司类型的用户需要什么以及为什么需要，它可以帮助我们创建需求的简单描述。

   在软件开发和演进过程中，随着产品和开发对产品认识的加深，需求总是在不断变化，所以，过早地进入需求细节以及对细节的描述，是一种时间上的巨大浪费。从这一 点来说，用户故事提供了一种恰到好处的粒度，使得产品在需求分析阶段能够极大地节约时间，并且使产品和研发人员始终把注意力集中在关键点，避免他们过早地陷入 细节以及被细节所局限，同时给产品功能留出了讨论空间，从而使产品有机会在讨论过程中得到优化。

用户故事的构建一般来说有三个环节:

1. 简单描述用户需求，

2. 围绕简单描述进行讨论;

3. 明确如何验证。

分别对应用户故事的三个元素，也就是3C:Card(卡片)、Conversation(谈话)、Confirmation(验证)。

Card(卡片)

“卡片”就是指对用户故事的简述（传统上人们通过便利贴在白板上构建用户故事），一个好的用户故事卡片包括三个要素：

1. 谁：谁需要这个功能；

2. 需要什么：想通过系统完成什么事情；

3. 为什么：为什么需要这个功能，这个功能带来什么样的价值。

Conversation（谈话）

谈话是指用户、领域专家、产品经理、研发之间围绕用户故事进行的讨论，谈话是明确需求细节的必要环节。可以用文字对谈话进行简要记录，此外，也可以基于图形或

其他工具进行讨论。稍后我们会介绍相关工具可以对用户故事进行挖掘和细化([使用Domain Storytelling挖掘用户故事](# 2. 使用Domain Storytelling挖掘用户故事))。

Confirmation（验证）

  验证代表了验收测试，描述了客户或者产品owner怎样确定用户故事已经被实现，且能够满足需求。一般可以用如下模板写Confirmation:

假设我是<角色>，在xxx情况下，

当我<操作>，

那么<结果>。

基于用户故事进行领域划分案例

   对于分解之后的用户故事，我们可以按照分离关注点的原则将其进行分类，将关注同一细分领域的用户故事分为一组，将这些用户故事形成的小组命名，即可得到各个子领域，同时根据用例之间的层次关系，也能得到各个子领域之间的关系。

---

来源：基于用户故事的领域驱动DDD（付资料下载）

---

系列阅读

如何运用DDD思想理解业务-CSDN博客

如何从零搭建10W QPS 高并发优惠券系统-CSDN博客