标签归档：软件开发

      本周虽然只工作三天，但却是超级忙碌的三天。开会、讨论文档耗尽了我的时间和精力。回想起来，印象最深的就只能说工作上的事儿了。

      和小戚阿飞一块整理业务架构是很愉快的事情，看着一大陀业务逻辑经过整理、讨论、再修改，慢慢形成条理清晰的业务对象搭建的架构，也小有一些成就感。
      最大的感触就是发现使用UML进行业务架构分析是很舒服的一件事情：
      首先用部署图描述了以后运营系统的逻辑划分和物理上的性能扩展性；
      然后用用例图描述了系统功能上现有的和要实现各个功能的关系，include和extend用在构建系统功能关系上，可以让OO的程序员们有共同的语言。画完之后，至少从宏观上看，系统下一步的演进意义所在，已经很清晰了；
      接下来关键Case里面就可以出活动图了，这种能够替代流程图的描述方法，每一个应用程序员其实都应该掌握的；
      宏观的告一段落后，下一步的对象模型已经是细致活。类图可以把我们需要的关键对象都描述出来；
      再后来，我们发现为了实现某些需要C/S共同配合的逻辑时，序列图也必须加进来
      希望下周能把所有悬而未决的业务逻辑都确定下来，这样业务架构才真的算功德圆满。

      连着两个上午的用户模型讨论，搞清楚了两件事：
        1. 在现有业务处理单元UID之上，引入新的账号单元是无法避免的；
        2. 已知的帐户、服务关系、订购关系等等，都要在原有处理逻辑的基础上，考虑对账号的处理；
      开始真的让人觉得很难接受，可以遇见的系统实现开销将会成多倍增长。但后来从大家抛出来的Story上看，UID也真的不适应了。真是变化快啊！

      用户模型是很让人惆怅的事情，不再提了。拉回来再说说运营系统优化。设计业务架构就是为了下一步系统优化。感觉干了也有一多半了，昨天下午就和小戚阿飞简单头脑风暴了一下后续的开发。
      先做原型，然后再一个产品一个产品的集成，这是阿飞上个项目的工作模式，全体通过。
      对这个原型的开发，我建议先搭架子，主要是API、DTO和DAO，形成闭环，然后一段一段的搞。好象有个专有名词说这个模式，拍脑袋想了半天，终于想起来了，好像叫迭代。

继续阅读 →