DDD-第二课

第二课:准确理解业务需求,持续探索领域模型

平时遇到的问题:我想做领域建模,但是我们的业务人员不重视。。。。

如何才能让大家意识到领域模型的价值?

image-20200718172323912

image-20200718172444511

需求分析的重要性

image-20200718172538066

需求分析的现状:

1.我已经讲了很多遍了,开发就是听不明白。——业务人员真是弱爆了,需求根本说不清楚。

2.能不能不要这么频繁的需求变更呀!——我没有改需求啊,原来就是这么说的呀!

3.能不能不要这么频繁的需求变更呀!——响应变化,需求变更很正常呀!

4.怎么已经开始编码了,咱们的需求还没评审呢!——不先编一点,来不及啊。。。

5.上线了。。。——又遗漏了业务场景。。。

准确理解业务需求,持续探索领域模型

image-20200718173250144

image-20200718173344943

课程大纲:

1.需求分析工具箱——需求分析技术概览;

2.时间风暴简介——用协作的方式进行全局业务探索;

3.静态模型和动态模型——在需求分析中梳理领域模型;

4.实例化需求和领域模型——用领域模型增强实例化需求的效果。

需求分析工具箱:

image-20200718174119957

1.用例分析:结构化的展开和分析繁杂业务场景;

2.实例化需求:解决自然语言的模糊性问题,用例子澄清需求;

3.用户故事:敏捷方法,强调现场客户、需求目标、沟通和确认;

4.用户故事地图:用户场景的全局观、探索发现和迭代规划;

5.事件风暴:面向复杂业务领域,擅长业务场景的挖掘;

6.影响地图:面向业务目标探索不同的解法;

7.其他。

探索和发现、沟通和共识是需求分析的本质

image-20200718204403802

从目标到细节,逐层展开

质疑、猜想、沟通、确认

是协作性的过程,发生在协作空间

使用统一语言,达成一致性共识

用例分析

用例(Use Case)是经典的需求分析方法,起源于90年代Ivar Jacoson的工作,是Rational Unified Process(统一过程)的重要组成部分。

image-20200718204547366

image-20200718204605250

用例解决的核心问题:结构化的分析繁杂的业务场景。

image-20200718204817705

执行者、系统边界、用例

场景、交互

目标、前置条件、后置条件、例外

用户故事地图

用户故事地图(User Story Mapping)是一种敏捷的用户故事可视化方案和协作方法,源自Jeff Patton。

image-20200718205032070

用户故事地图解决的核心问题:在业务目标比较清晰的情况下,探索渐进的业务解法,并据此规划迭代

用户、用户画像、目标

用户旅程、业务流程

骨架故事、替换和扩展场景

规划迭代

image-20200718205324403

事件风暴

事件风暴(Event Stroming)源自Alberto Brandolini,最早兴起于领域驱动设计社区。事件风暴在探索复杂业务领域,发现业务场景方面非常有效。

image-20200718205626745

image-20200718205653301

实例化需求

实例化需求(Specification By Example)是一种需求澄清实践,核心是解决自然语言的歧义性问题,通过例子详述需求,避免沟通歧义。

image-20200718205912011

实例化需求也被称为BDD(Behavior Driven Development)或ATDD(Acceptance Test Driven Development)

它可以被自然地过渡到自动化验收测试,同时由于测试即文档,实例化需求也是实现需求文档的最好方式。

事件风暴简介

点点共乘:

1.无车共乘;

2.顺风车;

3.共享巴士。

如果你是产品经理,你从哪个场景开始?

一个极简场景

用户A发布了一个出行计划,恰好和用户B的出行计划同起点、同终点、相同时间。经系统撮合,二人在约定的会合点见面,共同打车,在抵达后进行了线下结算,行程结束。

请思考:这个场景清晰吗?有没有什么潜在的问题?

事件风暴=事件+风暴

image-20200718211410789

事件:领域事件=业务视角的重要事件

image-20200718211723783

image-20200718212655552

事件风暴的过程中,领域模型同步产出。

静态模型和动态模型

image-20200718212902552

聚焦于功能,收敛于模型

image-20200718212956589

任何概念实体,如果它没有出现在场景中,这个概念实体就没有任何意义;

场景中的任何实体,都必然应该出现在领域模型中,以避免概念遗漏。

image-20200718213126200

用户发布出行计划

image-20200718220220878

image-20200718220252804

系统进行撮合

image-20200718220414096

image-20200718220534997

继续优化

image-20200718220823054

从示例中得到了哪些启发?

统一语言:任何在需求描述中出现的概念,都必须出现在领域模型中。如果需求描述中存在概念之间的关系,领域模型中也必须有这个关系;

领域模型:领域模型是需求分析的自然结果;

探索和发现:沟通过程也是探索和发现的过程。通过讨论,特别是通过显式化领域模型,尝尝能发现模糊的需求,或者新需求的线索,或者需要精确定义的术语。

实例化需求简介

上车点计算策略

image-20200718221511021

请思考:出现在实例化表头上的这些信息,在领域模型中应该有对应吗?

实例化需求

实例化需求的核心是使用例子来描述需求。同时它也是一个从目标出发的需求分析方法。主要手段包括:

1.以终为始:在开始开发之前,定义验收标准,明确需求应该构建成什么样;

2.共同参与:开发、测试、业务共同参与,即时、小批量地澄清需求;

3.构建需求金字塔:基于目标、操作流程、和规则构建需求澄清的金字塔;

4.从实例化需求到验收测试驱动开发:以实例化需求为基础,改变协作的模式和开发过程,实现验收驱动测试开发(Acceptence Test Driven Development)。

总结

image-20200718222628076

image-20200718223002464

image-20200718223036659