区分系统与业务的工程划分方法

区分系统与业务的工程划分方法

如何划分一个系统的源程序工程？这里提出一个基于系统和业务的工程划分模型，这个模型的特色是要区分出哪些是系统工程、哪些是业务工程。

本文只着重于客户端页面层，弄清楚页面层后服务端的工程结构应不难想象。为便于书写，咱们设计了一个场景：呼叫中心系统里跑档案和呼叫两个业务。

界面层

咱们来看看界面层内部有哪些源程序工程，以及它们之间的依赖关系，以下：

 

上面的cc-ui-core和cc-ui是两个系统工程，file-ui是关于档案的业务工程，ic-ui是关于呼叫的业务工程。这些工程之间的依赖关系如图中箭头方向所示。

该工程模型具备以下特色：

• 一个系统有系统和业务两类工程。
• 每一个系统分ui-core和ui两个系统工程，其中，ui-core工程被业务工程所依赖，而ui工程依赖其它各业务工程。
• 业务工程之间不发生依赖关系。一个业务页面不依赖于另外一个业务的页面，但同类业务的页面之间可（单向）依赖。
• 各工程之间不存在双向或循环依赖。

下面咱们看看该模型解决了哪一个问题。

系统会话

用户登陆后系统就肯定了当前用户的工做环境信息，咱们称之为系统会话。例如用户登陆进某呼叫中心后，系统会话就保存了该用户的呼叫中心ID。当用户为客户办理业务时，系统会话就充当了办理业务的工做环境。仍以呼叫中心为例，业务记录里的呼叫中心ID字段应无必要也不容许在业务界面里输入。

所以，咱们把系统会话放在cc-ui-core工程里，并让各业务工程经过依赖能访问到系统会话对象。

页面集成

至少有两种集成的情景。

• 菜单及工具条。例如，点击菜单后打开某个业务页面。这要求菜单依赖业务页面。
• 跨业务页面。例如，呼叫中心系统里有一个显示当天建档数和办理呼叫人次的页面。此时咱们应独立开发这个页面。

咱们把这些集成页面放在cc-ui工程里开发，该工程既能经过依赖cc-ui-core获取到系统会话，又能经过依赖各业务工程加载对应的页面。

数据集成

上面说到，两个业务工程之间不依赖。但页面需求灵活多变，例如，咱们须要在呼叫页面里打开客户档案，如何打开呢？

打开另外一个页面就须要知道该新页面的一些信息，但因为咱们不容许两个业务工程存在依赖关系，所以遇此需求时咱们可经过ui-core进行中转。例如，假设打开一个页面须要获取到其class才行，而且咱们又不但愿经过反射来获取，此时咱们可经过接口和依赖注入来完成，以下：

• 在cc-ui-core工程里建一个接口：

public interface Provider {
    Class<?> filePageClass();
}

• 在cc-ui工程里实现该接口。因为cc-ui依赖全部的业务工程，所以可轻易获取到所需信息。

• ic-ui工程因为依赖ui-core工程，所以可经过依赖注入获得该接口，并进而调用该接口的方法来获取到所需信息。

总结

咱们提出的工程模型可用这样一句话来归纳，即业务在系统里跑。系统一方面负责加载业务页面，另外一方面又经过传递系统会话辅助业务页面的开发。