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

引言

二十年前的我，还在学校里抱着一台DIY机（德州486+大众主板+16M内存+3.5inch软驱+昆腾320M硬盘，当时全校最快主机没有之一），揣着一本《Undocumented DOS》，沉迷在Pascal、C以及汇编混合编程的世界里无法自拔。二十年后，软件开发已远不是当初几张简单流程图可比，软件开发的方向由简至繁，各式的开发工具更是层出不穷，不仅让新出道的人们深感乱花渐欲迷人眼，也让我等备感跋涉之不易。所幸爱好不外有二，读书实中其一。也唯有不断学习，才不至被拍死在沙滩之上。

学习BDD，实属偶然。在学习ES+CQRS的过程中，我认识到必须要转变观念，把传统单一结构的领域模型一分为二，将其中反映系统状态发生变化的部分封装在写模型里，而将查询或呈现的部分封装在读模型里，分别设计、分别实现，再以领域事件为纽带，实现整个业务的最终一致性。因此，发掘领域事件、理解最终一致性成为个中的关键。因此，我开始寻求发掘领域事件的方法学支撑。

在搜索引擎帮助下，我很快找到了一些社区和Blog上关于发现和挖掘领域事件的文章，而它们的观点最终都归结为了一点： 讲好故事 。讲好了故事，才能清楚我们究竟要什么，才能帮助我们划清边界，才能发现边界间的联结关键。于是，很自然地，BDD进入了我的视野，然后是Specification by Example，继而是Impact Map。它们都可以帮助我们把故事讲好。

这一篇，先总结一下这段时间的学习成果。之后再争取学以致用，用一个具体的项目进行DDD+BDD的综合实践。

回首过往

既然是要在原有开发方法里掺入新的东西，那就说明现有方法必定有其缺陷，需要加以完善和改进。所以，先说说我们在此之前是怎么做DDD的。

• 刚开始，我们会有一个很原始、很初级的需求说明，大致说明项目的背景和主要需求。而这样的需求不外有二，或是改进现有业务流程，或发现新的价值增长点。接下来，是若干次的见面会，通过讨论和沟通，从客户处得到的用户故事越来越详尽，业务流程因此得到逐步细化，一些关键的概念也得以逐步澄清。于是，用文本描述的角色、用例以及领域概念成为这一阶段的主要产品。
• 然后，大家开始讨论如何为整个系统划定核心域和各子域，并尝试用UML类图和顺序图建立系统的模型、切分BC。最后，我们开始尝试用TDD实现系统原型，并借由一些简单的测试脚本，通过命令行窗口模拟系统的行为，帮助客户更好地进行反馈。在此之后，由获取反馈-改进模型-重构实现构成的每个迭代小节，成为我们的主要工作，也使得系统逐渐丰满和完整。

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

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