迭代重构对项目有着微妙的作用，重构不能够过早也不能够过迟，要刚好在需要的时候重构。对于重构我的经验就是，当你面对新功能写起来比较蹩脚的时候时，这是一个重构信号，此时应该是最优的重构时间。重构不是专门的去准备时间，而是穿插在你写代码的过程中，它是你编码的一部分。所以我觉得TDD被人接受的理由也在于此。

2.SOA架构下的显示端架构腐化

显示端的架构腐化我个人觉得有两个问题导致，第一个，原本显示端的结构在传统系统架构中可以工作的很好，但是现在的整体架构变了，所以需要及时作出调整。第二，显示端的架构未能及时的重构，未能将显示端结构进行进一步分离，将显示逻辑独立可测试。

这样随着SOA接口的不断增加，显示端直接将调用服务的方法嵌入到显示逻辑中，如，ASP.NET Mvc、ASP.NET Webapi的控制器中，包括两个层面之间的DTO转换。

按照DDD的上下文设计方法，在用户显示端也是可以有选择的创建面向显示的领域模型，此模型主要处理领域在即将到达服务端之后的前期处理。毕竟一个领域实体有着多个方面的职责，如果能在显示端建立起轻量级的领域模型，对显示逻辑的重构将大有好处，当然前提是你有着复杂的领域逻辑。（我之前的上一家公司（美国知名的电子商务平台），他们的显示端有着复杂的领域逻辑，就光一个显示端就复杂的让人吃惊，如果能在此基础上引入领域模型显示端上下文，将对复杂的逻辑处理很有好好处，当然这只是我未经验证的猜测而已，仅供参考。）

对显示端领域模型处理有兴趣的可以参考本人写的有关这方面的两篇文章：

.NET应用架构设计—面向查询的领域驱动设计实践（调整传统三层架构，外加维护型的业务开关）

.NET应用架构设计—面向查询服务的参数化查询设计（分解业务点，单独配置各自的数据查询契约）

原本干净的显示逻辑多了很多无关的服务调用细节，还有很多转换逻辑，判断逻辑，而这些东西原本不属于这个地方，让他们放在合适的地方对显示逻辑的重构、重用很有帮助。

如果不将其移出显示逻辑中，那么随着服务接口的不断增加和扩展，将直接导致你修改显示逻辑代码，如果你的显示逻辑代码是MVC、Webapi共用的逻辑，那么情况就更加复杂了，最后显示逻辑里面将被ViewModel与Service Dto之间的转换占领，你很难找到有价值的逻辑了。

3.有效使用防腐层来隔离碎片服务导致显示端逻辑腐烂

解决这些问题的方法就是引入防腐层，尽管防腐层的初衷是为了解决系统集成时的领域模型之间的转换，但是我觉得现在的系统架构和集成有着很多相似之处，我们可以适当的借鉴这些好的设计方法来解决相似的问题。

引入防腐层之后，将原本不该出现在显示逻辑中的代码全部搬到防腐层中来，在防腐层中建立起OO机制，让这些OO对象能够和显示逻辑一起搭配使用。

图1：