好在网络是强大的、墙外的风光总有美好的。在email、twitter以及group的轮番轰炸下，一切开始出现转机。首先是Julian May向我推荐了Gojko Adzic所著的《Specification By Example》一书，然后是作者Gojko、网友ChrisMatts等人的回复，为我指明了学习的方向。

Specifications by Example为我呈现了一个全新的视角：以Specification、Automation Test以及Living Documentation等文档为中心的交付模型（Documentation-centric model），以及一个由下图所示的交付模式。

随着阅读的不断深入，Why-Who-How-What被Goal-Actor-Impact-Deliverable所代替，其含义也越发地清晰起来：

Why – Goal - Why do you want this product? 为什么会需要这款产品？

Who – Actor - Who can help or obstruct us? 谁会帮助或妨碍我们？

How – Impact - How will they be impacted? 这会对他们产生什么样的影响？

What – Deliverable - What will the feature do to support the desired impact? 这个功能将如何产生期望中的影响？

之前那种依赖于语言本身对How和What进行的讨论，此时便显得如此拙劣。对此，Gojko有这样一段精彩的阐述：

But now I advise people not to think about that, instead to think about impacts and deliverables. Deliverables are stuff you do in your zone of control, impacts are how those things influence actors in your sphere of influence. You can call these questions "what/how" or "how/what" or not think about the questions at all, depending on what the group in the room understands better.

它回答了之前一直困扰我的问题。即What是在开发团队控制范围内的，能对Actor产生影响的那些事物。这些是我们努力就一定能做到的，比如系统能提供的具体功能。而How则是我们期望的、能对Actor产生的影响。这种影响相对开发团队而言，是间接和被动的。对此，Gojko用一个手机App进行了形象的比喻：

Impacts - this is your sphere of influence - things you don't control directly, but things you think you can influence. Deliverables - this is your zone of control. The big question to differentiate between the two is: is there an assumption here, or are we guaranteed to achieve it if we decide to do it. Eg if we decide to build an iPhone App, we will. But if we decide to get people to buy the app on the appstore more, regardless of all our efforts that might not happen. The first one is in our zone of control, the second is in the sphere of influence.

期间我对Business Goal也重新进行了认识。BDD in Action曾用Specific（特定的）、Measurable（可量化的）、Achievable（可实现的）、Relevant（相关的）、Time-bound（有期限的）对其进行说明，而发掘Goal的工具真的是如此简单——不停地问Why……然后，我又重绘了之前的图：

再补上MelvinPerezCx对Impact Map与各种产出件之间关系的一张好图：

继续前进

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

DDD+BDD的开发流程：

项目伊始，使用Impact Map勾勒出系统的功能轮廓。

找出Key Example，编写相应的Specification及Feature文本。

对领域进行划分，将Specification划入不同子域。

统一Specification中的概念，建立特定子域内的通用语言。

结合Specification的描述和子域的划分，定义最初的BC结构。

选择核心BC，利用SpecFlow+NUnit等工具，用代码实现Specification描述的Feature。

通过捕捉Feature描述中的Given-When-Then，得到领域事件列表。

逐个BC重复第6、7两步，得到领域模型的原型。

不断审视和完善Specification，中间可能夹杂着BC的调整，使领域模型不断演进和丰满。

利用SpecLog等工具生成领域模型的Living Documentation。

通过自动化测试，审视业务流程是否达到预期。

从领域模型由内而外，编写应用接口层、UI层和基础设施层的Specification。

使用BDD工具，实现这些外围Specification的自动化测试和文档生成。

经过若干次迭代，所有核心和外围Specification都得到完美实现。

系统通过集成测试和试运行，顺利交付并完成归档。

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

第3、第5步，对子域的划分和BC的切分是难点，因为两者并不一定是一一对应的关系。只是因为Specification的出现，可以让我们用更具体的示例来进行这种划分，而不是凭空地臆想。

第6、第7步，在实现Specification的自动化测试时，应高度关注各种领域事件及其触发的结果，还要从saga的角度去思考这些事件之间的协调配合。这在CQRS Journey一书中有相应的例子可作参考。

第6、第7、第8步，在编码的同时配合不断完善的UML类图和顺序图，应该能更好地反映系统全貌，或者帮助我们发现遗漏。

第12、第13步，UI的自动化测试一直是难点，也是我的弱项。尽管Specification by Example中有对UI自动化测试的专门阐述，但仍需要实践才能真正变成自己的东西。

在任何时候，专注核心域都是要放在第一位的。包括Specification的编写和Example的选择，都要以此为原则，才能避免陷入实现细节的泥沼。

写在最后