对结合BDD进行DDD开发的一点思考和整理(6)

解决了Impact Map的问题，下一步就是思考如何将DDD的战略思考与BDD的战术实现结合起来，引导整个开发的方向。这一切当然地需要用实践来解决，在前进中才能解决遇到的问题，所以暂且只得到以下的一个思路。

DDD+BDD的开发流程：

1. 项目伊始，使用Impact Map勾勒出系统的功能轮廓。
2. 找出Key Example，编写相应的Specification及Feature文本。
3. 对领域进行划分，将Specification划入不同子域。
4. 统一Specification中的概念，建立特定子域内的通用语言。
5. 结合Specification的描述和子域的划分，定义最初的BC结构。
6. 选择核心BC，利用SpecFlow+NUnit等工具，用代码实现Specification描述的Feature。
7. 通过捕捉Feature描述中的Given-When-Then，得到领域事件列表。
8. 逐个BC重复第6、7两步，得到领域模型的原型。
9. 不断审视和完善Specification，中间可能夹杂着BC的调整，使领域模型不断演进和丰满。
10. 利用SpecLog等工具生成领域模型的Living Documentation。
11. 通过自动化测试，审视业务流程是否达到预期。
12. 从领域模型由内而外，编写应用接口层、UI层和基础设施层的Specification。
13. 使用BDD工具，实现这些外围Specification的自动化测试和文档生成。
14. 经过若干次迭代，所有核心和外围Specification都得到完美实现。
15. 系统通过集成测试和试运行，顺利交付并完成归档。

对这个流程中，有几点需要说明：

• 第3、第5步，对子域的划分和BC的切分是难点，因为两者并不一定是一一对应的关系。只是因为Specification的出现，可以让我们用更具体的示例来进行这种划分，而不是凭空地臆想。
• 第6、第7步，在实现Specification的自动化测试时，应高度关注各种领域事件及其触发的结果，还要从saga的角度去思考这些事件之间的协调配合。这在CQRS Journey一书中有相应的例子可作参考。
• 第6、第7、第8步，在编码的同时配合不断完善的UML类图和顺序图，应该能更好地反映系统全貌，或者帮助我们发现遗漏。
• 第12、第13步，UI的自动化测试一直是难点，也是我的弱项。尽管Specification by Example中有对UI自动化测试的专门阐述，但仍需要实践才能真正变成自己的东西。
• 在任何时候，专注核心域都是要放在第一位的。包括Specification的编写和Example的选择，都要以此为原则，才能避免陷入实现细节的泥沼。

原文转自：http://www.cnblogs.com/Abbey/p/5143674.html

• 共7页:
• 上一页
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 下一页