DDD建模现场资料图

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修改过]

这样也行？
看起来是scrum会议形式在进行,
scrum团队就3-9人,白版上花花绿绿一般是Scrum sprint plan下story、task，
用项目管理的方式进行建模？

建模还是用UML更舒服，
模型是否合理，有时候还需要做做单元测试，用代码来验证验证，
这种会议建模能行吗？
[该贴被clonalman于2013-08-31 15:58修改过]

把story换成
boundaries for aggregates,
bounded contexts and subdomains

这倒是很有启发性

2013-08-31 16:13 "@clonalman
"的内容
把story换成
boundaries for aggregates,
bounded contexts and subdomains ...

见下图：


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

上面这张图类似Jdon分析法的横向坐标。
[该贴被banq于2013-09-02 10:54修改过]

动态跟踪这次DDD建模，新图片，向大家讲解模型：


一张开会的图片，至少展开介绍一下在干么？

2013-09-06 23:47 "@clonalman
"的内容
至少展开介绍一下在干么 ...

这是9月3日开始的DDBE首届会议的图片，大概内容如下：

四个人组成一个团队，使用大量纸张和粘贴纸，两个人扮演领域专家，介绍了一下Kazachstan学校，发给每个人一张Kazachstan学校报告纸，告诉他们学校需要更好的软件系统能够产生这些报告。同时，领域专家介绍了这个系统的复杂性：学生可以根据法律和政府法规以不同的方式进行评估，当然要注重一个学生进步的重要性以及对学生的保密性。

在两轮25分钟中，成员试图将问题域画入模型中，两个领域专家走来走去回答问题，类似现实领域的专家，提供成员需要了解的重要信息。

从第三轮开始，成员们已经开始从理解领域切换到一些也许有效的解决方案上，领域专家给予一些技术指导，比如如何从 Event Storming .开始，另外一个团队已经产生了非常详细和完整的模型，但是领域专家告诉他们按照他们这个模型教师时间花在数据工作上。没有时间教学了，这个团队不得不重新评估他们之前的假设前提。

每轮比赛后结果可能不同，有的使用UML画图，有的使用彩色粘胶纸，有的画了UI图形界面，但是他们都取得很大进步，对问题域的理解更加深入了。

最后，有一个简易的圆桌讨论，聚焦复杂的领域，其中很多人贡献了他们的见解所涉及的挑战。

注意，领域专家和主持人是两种不同角色，主持人要帮助领域专家推进问题解决， 不能离开问题域。

有时扔掉模型是一种好的办法，太爱惜自己的模型反而阻止前进。

使用 Pomodoro：Pomodoro－敏捷方式的时间管理，有几分钟的反馈证明非常有用的。 更倾向于提供的选项。

下面图片是他们分享在设计过程中的体会：如何上下文和需求紧密结合，界定上下文：
[该贴被banq于2013-09-07 09:55修改过]