使用用户故事映射实现领域建模 - pulse

在构建业务关键型软件时，像领域驱动设计这样的实践是把一个重要的焦点放在IT和领域专家协作上。此外许多公司还看到了与客户更亲密的关系，更好地了解他们的愿望和需求，从而建立更忠诚的客户群的必要性。这就是服务设计、用户体验研究和敏捷概念（如用户故事）的亮点所在。用户故事图能帮助我们设计出既可行又有价值，而且可用的软件解决方案吗？
“最好的解决方案来自需要解决问题的人和能够解决问题的人之间的合作”。-杰夫巴顿

你是在一家为客户着想的公司吗？或者说，你正在努力创造一个以用户需求和愿望为中心的解决方案？
也许你甚至试着与客户和他们的用户一起构建这些解决方案，通过使用模型、试验和mvp逐步构建，让他们参与实际设计？
您可能想知道，在这样的环境下，您究竟如何设计和构建一个可行的系统组合，以避免将未完成的组件与胶带、细绳和回形针组合在一起的风险，或者可能最终创建过于复杂的解决方案来满足任何未来的需要。
有很多关于演进架构的讨论，但是我们如何将其与客户需求联系起来呢？
为了建立可持续的系统，我们需要知道早期的原型将把我们带到哪里；我们需要能够看到更远的未来。简而言之，在这个高度敏捷的世界里，有什么可以帮助我们进行领域建模呢？
 
用户故事映射
用户故事映射是一种从敏捷社区衍生出来的实践，它是一种将用户故事结构化的方法，它是您正在构建的应用程序的最终用户体验到的，从他们的角度讲述故事的一种方式。从这个可视化工具中获得的见解，无论是产品发现、领域知识、交付计划和团队协作，都将直接连接到这个焦点，即用户体验。
在许多敏捷方法中，用户故事已经成为描述用户想要什么的一种常见方式，无论是XP的起源地还是流行的Scrum框架。尽管这从来不是一种新的编写需求的方式，但许多团队仍然在处理大量的、非结构化的、一维的产品积压问题，这些积压的故事被写成一个详细的愿望列表，就像过去的需求文档一样。很难很好地处理这个列表，尤其是以一种好的方式对其进行排序和分解，以便以可持续和一致的方式使结果最大化。
将故事映射到用户的过程中，以及执行的所有活动和任务，打开了一个新的维度，在这个维度中，可以更容易地找到需要一起构建的内容，以使应用程序可用，并分成可行的产品增量。然后，设计可以以一种进化的方式完成，每一步都可以潜在地摆在用户面前，从而缩短基本的反馈回路。

进行这种映射并从开始到软件交付的整个过程中使用它的一个微妙而重要的影响是，设计与用户交互明确地联系在一起。人们不能再简单地从所有相关的涉众那里收集一长串的需求。每件事都必须映射到某些用户活动上，迫使设计者从用户的角度来看待一切。用户故事概念开始变得有意义，正如它最初的意图；它是关于它是如何使用的，而不是它是如何写的。
故事映射非常适合作为设计过程中所有利益相关者的协作工具，从最初的构想和开始，创建连贯的客户旅程，通过构建阶段，到初始之后产品的持续丰富和维护交货。
它涵盖了产品的所有三个“-ilities”：可用、有价值和可行。
它对服务设计师来说很有意义，因为它涵盖了大部分客户旅程和体验（CX 和 UX）；非常适合产品发现，让产品经理很容易描述产品的意图和目的；它是技术设计人员进行领域建模、通过弥合问题和解决方案空间之间的差距来创建可行解决方案的好方法。

“当工程师抽象地考虑“客户”而不是真实的人时，您很少会得到正确的结果”。– Gene Kim
 
领域建模
尽管用户故事映射主要是一种产品发现和开发工具，但它也有利于领域建模：因为它以非常清晰和全面的方式描述了问题空间。
在设计技术解决方案时，问题空间的复杂性往往没有被很好地捕捉到，导致基于现有技术解决方案的幼稚设计或架构师和技术专家对以前经验的重用。相反，设计应该由对问题空间的深刻理解来驱动，故事地图是一个很好的工具。
它为设计师提供了必要的由外而内的视角，以用户对要构建的产品的心理模型为指导。除了故事映射所支持的进化设计之外，这还强制实施了技术设计的进化方法。
领域建模者的故事映射的一些具体要点：

• 查看哪些数据需要一起显示和保存，有助于识别有界上下文。
• 为每个有界上下文识别无处不在的语言，不仅基于领域专家的业务术语，还基于用户体验。
• 识别需要事务绑定的数据以及最终可以保持一致的数据。
• 查找聚合及其数据和不变量。