DDD建模现场资料图

13-08-27 banq
                   

Mathias Verraes (@mathiasverraes) 在Qandidate.com 现场进行DDD建模风暴会议图:


从图中可以猜测出,使用有颜色的贴纸作为一个领域模型,一堆在一起代表一个有界上下文。

见原文:Facilitating Event Storming

Domain-Driven Design modelling for Agile teams, Brandolini-style. 敏捷队伍的领域驱动设计建模。

有三个理由需要领域建模:

1.尽早发现复杂性,寻找丢失的概念,理解业务流程。

2.建模尽可能细节地解决一些特定问题

3.学习如何建模 以及如何进行建模思考。

作为主持这场头脑风暴的主持人的技巧(Facilitator tips):

1. 首先将自己沾牢

2.知道什么时候往回走,不做建模,而是指导建模

3.询问问题:

这里还有遗忘的什么东西吗?为什么有差距?

怎么做赚钱?

评估业务是如何运行的,目标是什么,我们如何知道已经完成这些目标?

对于谁哪些事件是重要的(最终用户 业务 承租人)

我没有在这个模型中看到特别的角色,它们应该存在这里什么地方?

4.改变方向,从流程结束处开始,及时回滚,然后再从出发点开始出发。

5.打断长的讨论,从意见对立面角度想问题,询问两边意见。

6.时间段管理(25 分钟).每段时间后, 询问好的进展是什么,坏的是什么,然后转移到下一个阶段,即使你没有感觉到模型完成,也可以转移一下话题。

7.持续地为热点讨论开辟新房间。

8.只要感觉存在问题就悬挂问题标签等

9.最后,别忘记拍照,然后告诉他们将这些模型抛到脑后,隔天再来继续。

10.个人喜好用句式语法命令事件,如一个产品被加入了购物篮和产品加入了购物篮,这种语法表达会使参与的业务人员感觉比较舒服。

[该贴被banq于2013-08-29 10:37修改过]

                   

1
clonalman
2013-08-31 15:43

这样也行?

看起来是scrum会议形式在进行,

scrum团队就3-9人,白版上花花绿绿一般是Scrum sprint plan下story、task,

用项目管理的方式进行建模?

建模还是用UML更舒服,

模型是否合理,有时候还需要做做单元测试,用代码来验证验证,

这种会议建模能行吗?

[该贴被clonalman于2013-08-31 15:58修改过]

clonalman
2013-08-31 16:13

把story换成

boundaries for aggregates,

bounded contexts and subdomains

这倒是很有启发性

banq
2013-09-02 08:19

2013-08-31 16:13 "@clonalman

"的内容

把story换成

boundaries for aggregates,

bounded contexts and subdomains ...

见下图:


banq
2013-09-02 10:53

我个人认为上面这张图和Jdon分析法的图比较类似:

上面这张图类似Jdon分析法的横向坐标。

[该贴被banq于2013-09-02 10:54修改过]

2Go 1 2 下一页