软件的逻辑层次

基本层次

软件的逻辑结构可以划分为下面四个基本层次：

从下往上依次是：

1：基础设施层——这个层次是纯技术层次，解决的是系统的物理问题，比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大，是系统的物理条件。

2：business对象——在这个层次上，业务要素出现了，业务领域中的概念在这里实现。比如一个航运公司的系统，这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。

3：business流程——这个流程不是指程序解决问题的流程，而是用户的商业活动的流程。他体现的是端到端的业务流程。比如：检票员为旅客办理登机牌。business流程的输入参数是business对象，输出参数是business对象，产生的异常也是business对象。business对象在这里组合、串接，实现业务流程的自动化。这个层次是在直接实现用户的需求。

4：UI和接口——这个层面调用business流程，将执行的结果交给软件的用户，或者别的系统。

这种逻辑层次划分是最基本的情况，各种复杂的层次都是这种方式的一种扩充。比如下面这样的形式：

在基础设施层和business对象之间，加入了一个DAO层。DAO层一方面负责数据的存储，体现了数据的存储方式，另一方面体现了业务对象的属性。这样就使business对象只需要负责纯粹的业务逻辑，不用关心物理问题。简单的说，业务对象里面不需要写SQL语句了。

business对象和business过程之间，加入了Service层。business对象也是具有行为的，但是这样的行为是比较细微的，需要调用者在多次调用之间保持必要的状态，需要用Service层来做一个封装，更明确的表达业务含义。

单元测试

单元测试需要关心一个问题：层次之间的依赖关系。如果要测试某一个层次上的对象，必须同时建立他所依赖的每一个对象。层次之间的依赖越简单，测试越容易。

逻辑层次之间原则上是由上至下的依赖关系，同一层次内部的对象可以互相依赖。跨越层次的调用也是允许的，比如在UI Process中调用Business对象。UI层和UI Process层之间存在着互相的依赖。开发中我们最希望测试的是这三个层次：business过程、service、business对象。我们只要对下层对象建立stub对象，就可以对这三个层次上的对象进行测试。

对这三个层次的测试结果不仅保证了程序的运行时正确性，也是对程序的业务流程进行测试。在开发过程中和维护过程中，某个业务流程发生了变化，可以用单元测试保证其他流程不会受到危害。这样的构架可以保证迭代开发过程。

和物理层次的结合

上面说的都是系统的逻辑层次。在系统中还存在着另一个层次——物理层次。逻辑层次的目的是简化程序的逻辑复杂度，便于开发和维护；物理层次的实现需要考虑实际的物理分布情况，合理的安排每个物理节点的任务，最大限度提高系统的性能。逻辑层次和物理层次的划分依据和划分目的都是不一样的，他们之间存在着联系，但也不是绝对的。

逻辑层次和物理层次的结合有两种方式：

1、在基础设施层解决掉物理分布的问题，建立一个分布式的对象容器，把business对象和service放到容器中。这样，business对象和service就不必处理复杂的物理分布问题，business过程也不必关心他所调用的对象是在什么位置建立的。这样的方式最大限度的减少了物理结构对程序逻辑结构的影响，增加了物理分布的灵活性。但是在大部分情况下，对系统的效率都是有危害的。

2、在business对象内部处理物理分布的问题，或者制定一个技术无关的接口来体现business对象，在各物理节点编写各自的实现。这样物理层次和逻辑层次是搅在一起的，使系统的逻辑结构显得混乱，但是可以达到较高的运行效率。

这个帖子变成入门讨论了，也算是有了正确的归宿。我只是想普及一点基础知识，看到n个人在这里讨论对UI和DAO搞JUNIT测试，我觉得这样的普及是必要的。