如何保证架构设计的稳定性------项目前后两次架构设计对比
计费中心一期已做完，今天重新根据已开发的代码画了下类图和时序图，发现和项目开发之前画的有了很大变化，这说明之前的架构设计缺乏稳定性，经不起开发细化过程中的推敲。因此有必要对比一下改动点，吸取经验，争取在下次做架构的时候考虑更全面。下面以周期性批价计费这个场景为例，首先看看开发前的类图：
再来看看开发过后的类图：
通过对比发现存在以下问题：
- 没有高类聚导致没有低耦合。开发前的设计没有把每个类和方法的职责考虑清楚，导致在开发过程中无法很好的复用，以至于需要拆分类和方法，以提高可复用性，降低耦合。
- 类设计缺乏层次。在重构过程中需要增加类的层次，以提高代码可复用性。
- 缺乏对业务更进一步的细化，导致设计比较空洞，没有很好地体现业务。
当然以上的问题不是都需要在设计之初解决的，比如增加类层次性和提高可复用性都可以在代码迭代重构中逐步完善。
下面看看开发前的时序图：
再来看看开发过后的时序图：
通过对比发现存在以下问题：
- 业务流程考虑有较大误差，主要体现在容错方面
- 增加了任务管理和批价代理两个服务组件，提高可维护性和性能
总的说来，开发前的架构设计基本吻合之开发过程中的需求，但在更贴切地体现业务、高类聚低耦合、可维护性、容错、性能、类的层次性等方面还欠考虑，有待以后的提高
智能推荐
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。