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

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

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

界面层

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

上面的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工程，因此可通过依赖注入得到该接口，并进而调用该接口的方法来获取到所需信息。

总结

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