感谢各位非常专业的回复，我收获不少。
其实在事务处理时，确实需要根据场景来权衡。两段式提交虽然在一定程度上保证了结果的一致性，但同时也制约了系统的水平扩展。针对第三方服务，如何来协调和通信，以尽量保证结果的一致，对设计来说，是一个挑战。我能想到的，除了分布式事务外，就是看是否能通过协调器，根据各个原子事务的结果标志来协调，并根据不同结果发出不同的通信，进行对应的处理。

@jiaxingseng
MSDN订阅应该可以获得TFS，不过我不知道TFS有没有License限制，以及对服务器数量的限制。
其实这些工具基本都是客户来选择，我们提供推荐。即使要我们来推荐，自然还是Mingle+Go+Twist的好罗。

看来大家都比我厉害，哈哈。我确实没有仔细去想。不过这样也好，以后还可以改变硬盘大小。

specified) as the Guest OS claim disk space.
关键还是括号中的内容(up to the size specified)。只有这里才说明了这里所谓的dynamically expanding是有限制的，就是你指定的容量为最大容量。
我在文章中并非是说Virtual Box有什么问题。事实上是自己没有看清楚。但不可否认的是，有很多人都产生了误解。可以在Google上搜到。或许是英文对于我们而言，太不醒目了。不过，我觉得这种关键信息，最好还是highlight的比较好。...

@硅谷之浪子
还有一点很重要，购买TFS的费用也许比较高。呵呵:)

@程序诗人
我的英语也不好啊。这两周的感受是，老美说话语速普遍较快，而且听起来好像没有断句。最关键的是，他们不一定要用什么重词，而是习惯用许多简单单词组成的短语，这反而加大了我们理解的难度。所以，我觉得可以看看老友记之类的美剧，最好是有英语字幕的。我现在也在加紧学习啊。
@dotNetDR_
我也不了解。
@木耳
我们Team工作在一个房间，故事墙就是房间墙上的白板。故事墙必须在团队成员都能看到的地方，也是我们开站会的地方。
@Tony Zhou
用Cucumber吧。

@nU||
你若觉得烦，你可以不看。我写我的博客，就得照着我的习惯来。我随意地写，你随意地看，不就结了。
你觉得我有文艺腔，不错啊，非常Nice，多谢！

@chenkai
团队是提倡Switch Pair的。每天站会都会提出。不过Switch的频率也需要掌控，太频繁了，则缺乏知识的延续性。

样运行良好。我们不是故意为之，而是根据项目需要，客户情况，团队能力等多方面来考虑技术选型。...

写这篇博客，就是希望寻找答案。

@hchxxzx
换了一个模板，感觉要好些。

@hchxxzx
你可以放大再看。我用Live Writer发布的，大约是这个样式的问题，而不是排版问题。
如果你觉得吃力，可以访问我的网站：http://www.agiledon.com/?p=539

@道法自然
所以在之前的模块划分是很重要的一个环节，它由此可以避免沟通不足带来的问题。

@道法自然
说到底，API设计的最大难题还是兼容性问题。

@水木年华
接受你的建议。有时候我也觉得自己太罗嗦了。

MMN（Macro-Micro-Nano，即宏观-微观-纳米）实用架构过程初步体现了我的架构观：即以实用主义态度把握架构原则与本质思想，从系统的各个层次剖析架构，提供一个具有指导意义和实施价值的架构过...

@Lumj
你去了解一下DSL，好吗？

@吾爱孟夫子
一般我会让RowHeaderExcelElement接受ReportRowHeader。
Adapter的使用是没有问题的，它仅仅是为了让WritableSheet能够适配ReportCanvas。与ReportCanvas的抽象无关。
你后面提到的抽象工厂是对的，这样可以避免传递错误的DrawingElemnt到ReportCanvas中。

@Lumj
请从方法签名来看，方法的名称体现了领域逻辑。连续的调用，就好似发出多个与领域有关的命令，就好似业务流程一般。所以才说是“自我阐述的领域逻辑”。

@netfocus
两者的含义是不一样的。Message Chains破坏了封装，将过程暴露了出来。Fluent Interface虽然看起来仍然是Message Chains，但它所公开出来的方法都是必须的，而且这些方法之间并没有中间对象，因为Fluent Interface返回的是对象自身。

@东风31
你说的有一些道理。主要还是例子的问题。其实通过这个例子可以说明对象自治、行为扩展以及适配的重要性。但这三点内容都需要大幅内容来讲。所以重点就讲了对象的自治。
另外，这篇文章算是书稿的草稿。讲解得不是太细，作为书稿的时候，就会充实，争取讲透彻。
还希望你能多提意见。

@Jack Fan
我使用的Live Writer。在Live Writer中格式挺好的，估计是博客园的样式问题。我自己的个人网站上格式也是好的。你可以访问我的个人网站：http://www.agiledon.com

上面的是Java中的代码。

@风云
不错，其实AnalyticResult与TaskScheduler都是参考了.NET异步调用的实现。只是文章中对其进行了简化而已。

仔细看了这篇文章，觉得怪怪讲述的就是实用哲学。

看到这篇文章。最先没有注意是谁写的，看了两段，吓，这腔调怎么这么熟悉呢？我猜是怪怪，一看，果然是。

这个似乎2009年微软就在创新日上推广了。这算是一个Web的生态系统，可以将很多开源的东西纳入到这个生态圈中。有点像是各类型Web 2.0的安装和管理Portal。

其实我在文章末尾也提到了，DataAnalyzer相当于是一个业务的Facade，所以它可以不用做抽象。而且，在DataAnalyzer中，根本就没有封装任何业务，所有业务的执行，它都委派给了其他对象。所以，根本不存在所谓暴露实现细节的问题。

@风云
我承认面向接口设计的重要性，不过这里对于“接口”的理解可以宽泛一点，而不是近限于抽象类型的接口。方法签名也可以认为是接口。
“我基本上对你的设计完全赞同。”你这句话说得挺逗的，有武林外传的风范。

@风云
谢谢！
没有抽象为接口是从场景的角度来考虑。由于我不再考虑DataAnalyzer本身的变化，而是将要变化的职责分离出去，交给了Task和Agorithm，所以就不再抽象。另外，不明白你所说的：隐藏内部实现细节的意思。不知道你对封装的理解是什么？其实，从广义的角度来看，我为DataAnlyzer定义analysis()方法和output()方法，就已经完成了封装。根据对象的含义，实现细节也已经被隐藏，所以你的意思我不明白。