分步开发的应用系统，如何处理共用模块？
大家好，在这里请教诸位一个问题，希望大家能不吝赐教！

说一下我的具体情况，我目前供职于一家单位，从事全市的承压设备的监检工作（安装监检和在用监检）。所谓承压类设备，包括压力管道、压力容器、锅炉，罐车等等。按照领导要求，准备将单位内的管理工作都实现信息化。但是，目前的技术实力、经济实力和时间要求，无法通盘设计实现一个大系统，所以准备分步实施信息化工作。

第一步就是将压力管道的工作信息化。那么，在设计《压力管道检验管理信息系统》的时候，我发现，有很多模块是未来多个项目都共用的。比如，【部门组织结构和员工管理】，我在压力管道系统中实现了，未来如果上压力容器的管理系统，肯定也需要开发这样类似的模块。再比如，【合同审批流程】也是一样。所谓合同审批是这样的，比如在压力管道的各项监检中，都需要和客户谈合同，然后这个合同需要提交部门主任审核，分管领导审批。同样，在未来的压力容器或者锅炉的信息系统中，我还要开发类似的模块。同样的，类似的模块有【费用管理】，我要知道每一个合同的费用执行情况。等等等等。

所以，我在这里向大家请教，对于这些通用的模块，我该如何设计？才能在未来新系统的开发中，能够复用这些模块？或者，大家有什么好的思路，好的书籍可以推荐我学习的？谢谢！

当然，要说明的是，对于这些模块，我知道所有的系统都要有，但是目前并不明确，每一个系统对这些功能的实现明确的要求。举例来说，我知道【合同审批审核】，但是，对于压力管道，我目前调研明确了是2级审批。而压力容器的合同审批我还不明确。虽然我知道这肯定是要有的！
------解决方案--------------------
关键字：工作流
Keyword:Work Flow

------解决方案--------------------
对于应用系统扩展，这是个很有意思的话题，很多软件厂商在推销时都打着可扩展的旗子，但其代价就是高额的后期费用，而自己开发的软件想后期扩展却往往因为人员的更迭而举步维艰。根本来说是因为两点：
1. 代码可读性太差，
2. 信息系统应用的关联性太强。
  重复代码仅是一个方面，假设我们将组件封装的非常彻底，我们在应对新的需求时也会遇到底层无法满足的情况。需要重写很多内容，最后还不如推到重来。

   因此对于不断扩充的应用开发需求，比较好的方式是采用面向业务编程模式，这是我的创造，可以参见博文http://blog.csdn.net/etudiant6666/article/details/8070634。
在这种模式下，各种逻辑都归结在业务中，并且可以很容易的展现相互关系，又都是中文的，因此可读性会很强，同时所有业务的关联性都可以追溯，比如下面的条件设置截图，直接显示了条件的调用位置。



利用这种平台构建的系统，就很容易进行扩展了。现在有个试用版，可以试试：http://www.puzhijie.com/download.aspx


------解决方案--------------------
微软的工作流并不适合中国国情。

不管是合同审批、请假审批、资源审批，

必须把这些所有的审批都抽象成一个相同的东西才行，就像Unix把硬盘、网络、打印机、各种设备都抽象成文件一样。

没有这种归纳和概括，你所谓的公用模块，就是一个妄想。


------解决方案--------------------
我该如何设计