系统 & 改革

《DDD》 Chapter 4 -The Smart UI "Anti-Pattern"里面一段话，描述不使用域模型（甚至在UI里面实现逻辑）的优势和劣势。
“Advantages

·         Productivity is high and immediate for simple applications.

·         Less capable developers can work this way with little training.

·         Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests.

·         Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be easy.

·         Relational databases work well and provide integration at the data level.

·         4GL tools work well.

·         When applications are handed off, maintenance programmers will be able to quickly redo portions they can't figure out, because the effects of the changes should be localized to each particular UI.

Disadvantages

·         Integration of applications is difficult except through the database.

·         There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply.

·         Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options.

·         Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.“

用来总结我当前公司的供应链系统，再合适不过了。

当前整个供应链由多个子系统构成，系统间没有直接的通信，主要在数据库层面集成。各系统今年刚从VB的实现转成C/S结构的.NET实现（主要为实现Remoting Facade ），大致采用.Net Example Duwamish架构（Table Model）。因为整个系统用的时间比较久了，数据库相当庞大，业务逻辑相当分散，整个系统基本上是DB Centric，维护性和扩充性并不理想。

这样一种现状，我想大概由公司建立之初业务快速发展，系统需要快速实施，而系统建设资金投入也相当有限造成。虽然系统问题多多，但毫无疑问这样的系统在过去的几年中加速了公司的业务发展。

 

随着业务的进一步发展，我想，如此结构的系统显示的竞争力将越来越弱，甚至成为制约业务发展的瓶颈。业务量越大业务越复杂，系统维护的代价越大，开发人员的主要精力将放到系统维护上。新的业务无法快速实施到系统，业务人员和开发人员的人力投入也将居高不下。

 

平地起高楼并不是最难的，更难的是要将如此一个大型系统完全改换成另外一种架构实现。感觉好象计划经济改革成市场经济，不知道对一个企业级系统的改革需要什么时机怎么个过程，不过可以预想

l       操作流程的改变，直接影响到界面用户体验。用户可能已经习惯了老的不合理或低效的界面操作和流程，对他们来说新的系统会带来阵痛，但是很快会被新的系统所吸引。

l       整个系统有统一的规划，而不是每个Team各自作战。提高系统内部组件及系统间服务的重用性，提高开发效率和质量。

l       系统架构向SOA方向发展，实现Business Process Engine统一管理业务流程

l       分析设计人员，建立商业模型->业务模型->Run-Time Model & DB Model，整个开发基于模型驱动，团队间的沟通和后续的维护也是以模型为基础。

l       开发人员，需要更强的OO基础，降低系统内部的耦合度以及系统之间的耦合度，构造robust的系统。

l       数据库的迁移，即使采用O/R Mapping，数据库还是免不了进行局部的重新设计，将当前的DB Centric的系统改造成Domain Model Centric的架构，数据库迁移无疑是个巨大的工程。

l       最难处理的大概是系统的过渡实施。多个子系统同步过渡还是单步过渡，沟通管理层与业务部门完成整个过渡过程将是个艰巨的任务。

最后，新的系统成功实施，多少年后又一次适应不了业务的发展，于是再一次改革。