业务模块的定义规则

普通模块定义

我们通常将业务模块定义在 views目录下。通常有如下最佳实践的规则：

一般模块都会包含大于1个的组件，因此在模块下需要定义文件夹而不是文件；
文件夹一般需要包含components子文件夹，作为该模块的子组件存放区域；
一般主文件都为index.vue或index.js，这样的好处是webpack在解析载入路径时默认会查询该名称，因此我们在import时可以忽略该文件名称，使写法更简单。例如 import BaseComp from './views/components/BaseComp';
子组件名称定义时，即文件名称和组件的name都为大写开头；

我们以用户管理组件为例子，首先，其目录结构应该如下：

组件中如下定义：

import Search from './Components/Search'
import List from './Component/List

export default {
  // 组件名称与文件名称保持一致
  name: 'UserManagement',
  components: {
    Search,
    List
  }
  ...
}

通过以上定义，我们就完成一个业务模块的基本定义了。

复杂嵌套组件的定义

我们有时候会遇到业务功能非常复杂的模块，必须将其拆分成若干组件，这些组件又会继续拆分和细化。那么我们经过实践发现，按照业务功能和页面布局来拆分组件是非常有必要的，同时在目录结构上也需要保持一致。这样在日后才能保持非常好的可维护性和可阅读性。

这里我们假设有一个负责的用户管理模块，其页面布局和部分流程大致是如下：

我们这里可以看到一个普通的用户管理模块中有一个授权部分，它里面包含了普通的表单和一个动态自增行的组件（DynamicList），而添加按钮又会弹出一个权限选择的PermissionTree页面，所以这里我们可以将自增模块和权限部分抽离成独立组件来使用。

那么我们可能会创建如下的目录结构：

我们可以看到在子目录Auth（授权模块）中，我们又分出了一个Components文件夹来存放该组件的子组件。这样的好处是可以一目了然的看到组件之间的层级结构。我们所有以组件划分的结构都会保持清晰的一致性。

实际开发时，如果遇到类似[权限选择]这样的单独组件，我们一定会抽离成全局公共组件，因为像这样组件一定会在更多地方用到（比如用户，角色，权限等基础模块，或者是其他涉及到权限选择的业务组件中）。所以抽离成公共组件，提供必要的出入数据接口（props & events）是最合适的。

我们在日后遇到更加复杂的组件，只要按照以上的实践来拆分就可以了。最重要的是保持一致性以及命名意思的简单，容易理解即可。

业务模块的定义规则