2004年9月29日星期四

项目已有的架构是源于微软的经典企业应用范例：Duwamish7,因此相信这样的架构应该是适合我们目前的业务规模，但是为什么在实际应用中项目还是出现了代码重复，逻辑混乱，维护困难呢？我想很大的因素是对Duwamish架构的思想没有很好的理解，而只是在工程的形式上照搬了，加之开发的功能之间没有进行统一的抽象（因为功能需求是一点点提出的，往往是一个功能开发好了，过一段时间另一个需求会提出来），结果就像是狗皮膏药一层层的贴到原有代码上。

在今天看过了CSDN的“Duwamish7大剖析”这篇文章以后，“重构”这个词逐渐的从我得脑海里浮现出来。既然Duwamish架构是基于.net的技术本身的适合中小企业应用的，那么在重现研究这个架构的思想以后，比对已有项目在设计上的不足，然后“重构”！（不过还没有详细的学习过Flower Martin的“Refractoring”不知道这个术语是否适合我目前想做的事，不过这是能想到的最适合的一个吧！） 我想关于基于.NET的Duwamish架构的一些原则性的讨论应该可以在Flower Martin的另一本书《Enterprise Architecture Pattern》中找到一些根据吧！

目前项目的开发首先缺少一个能对架构有清楚的认识的人，同时功能的设计完全由设计人员自己进行，如果这个设计人员同样不是一个对架构认识清楚的人，那么他的代码就开始腐蚀健康的架构！那么如果通过这次整理使得开发人员都对架构的思想有了很好的认识，那么将来是不是需要在进行新功能的设计时对它是否很好的符合架构的要求进行评估？而如果发现架构本身有缺陷需要修正时，这部分工作由谁来完成呢？