以客户管理为例，说明一个模块的目录结构。目录结构图片如下：
一、目录结构由四层组成，分别是：区域、模块，代码分区、代码类别。
二、kh代表是的客户区域，该区域下面放的都是客户管理相关的模块。
三、模块说明。
（1）main代表一个模块，在此是代表客户中的主模块。在图中可看到，客户区域下面还有两个模块：notpad和outBox，分别代表客户记事和邮箱帐户，此处我们以main模块作详细讲解。
（2）此处的模块，指的是物理模块，即对一个或一组bo对象相关操作功能的代码实现。分模块的原则是：一个bo对象或一组紧密关联的bo对象定义成一个模块。例如：此处的客户、联系人、客户分类、客户来源等一系列和客户紧密相关的一组对象，定义在的一模块内。
（3）逻辑模块指的是一块逻辑功能的调用入口。如：我的客户管理、联系人管理等，逻辑模块可以被菜单引用。可将一个action定义成一个逻辑模块，也可定义成多个，但最好一一对应，这样整个程序结构显的比较清晰。一个物理模块中，可以定义多个逻辑模块。具体逻辑模块的定义参见“模块的定义”中的说明。
四、inside和jk分别代表代码分区，表示一个模块的内部和对外接口。
五、inside内部分区中的代码分类：
（1）action：struts2框架中的action定义。一个action可以代表一个逻辑模块，一个定义成多个逻辑模块，详参见“模块的定义”中的讲解。
（2）bean：细粒度的业务逻辑处理，被service调用，用来实现业务代码重用。
（3）bo：bo对象定义，和数据库一一对应
（4）other：其他，如：DWR对象、常量定义、对其他模块的接口(其他模块/jk/inf)的实现（例如：在某个用户被删除时，我们希望该用户的所有客户，全部转入部门库，就可以去实TriggerUserDeleteInf接口，将客户划转的逻辑写在该实现中，并将该实现加入到接口中的常量列表中，就可以保证，在用户被删除之前，该实现被调用。这样一方面实现了不同模块代码之间的解耦合，也避免因为数据库表外键而导至用户信息删除报错。）
（5）service：业务逻辑处理，有时可能调用bean