Commit de55333c authored by Junling Bu's avatar Junling Bu
Browse files

update[doc]: 更新文档,以及创建开发交流群。

parent bba0c86c
...@@ -102,7 +102,7 @@ litemall ...@@ -102,7 +102,7 @@ litemall
1. [系统架构](doc/1.md) 1. [系统架构](doc/1.md)
2. [基础子系统](doc/2.md) 2. [基础子系统](doc/2.md)
3. [程序子系统](doc/3.md) 3. [商场子系统](doc/3.md)
4. [管理后台子系统](doc/4.md) 4. [管理后台子系统](doc/4.md)
5. [商场子系统](doc/5.md) 5. [商场子系统](doc/5.md)
6. [下一步计划](doc/6.md) 6. [下一步计划](doc/6.md)
...@@ -194,3 +194,13 @@ V 3.0.0 完成以下目标: ...@@ -194,3 +194,13 @@ V 3.0.0 完成以下目标:
* 其他任何有意义本项目的行为 * 其他任何有意义本项目的行为
个人能力有限,欢迎一起开发。 个人能力有限,欢迎一起开发。
目前litemall开发交流群:
![](doc/pic/qq.png)
注意:
> * 这是开发交流群。
> * 如果用户开发使用中有问题,建议采用Issue来报告问题和解决问题。
> * 在开发交流群中应讨论开发、业务和合作问题。
> * 交流结果如果是共识性的则在文档中记录,如果是开放性的则会在Issue中记录。
\ No newline at end of file
...@@ -519,3 +519,18 @@ https://docs.spring.io/spring-boot/docs/1.5.10.RELEASE/reference/htmlsingle/#dep ...@@ -519,3 +519,18 @@ https://docs.spring.io/spring-boot/docs/1.5.10.RELEASE/reference/htmlsingle/#dep
./deploy/util/lazy.sh ./deploy/util/lazy.sh
``` ```
### 1.5.4 分布式云部署方案
目前没有测试过,但是简单的分布式应该是可行的。
由于本项目是面向微小型企业的小商城系统,因此预期的分布式部署方案是
1. 专门的云数据库部署数据
2. 一台云主机部署管理后台的后台服务
3. 一台云主机部署管理后台静态文件服务
4. 一台云主机部署小商场的后台服务
5. 专门的云存储方案
因此,如果需要实现互联网式分布式云部署,目前的项目架构和方案会存在很多问题。
至少每个功能模块应该是独立服务系统。此外,需要引入单点登录系统、集群、缓存
和消息队列等多种技术。
...@@ -3,9 +3,9 @@ ...@@ -3,9 +3,9 @@
目前litemall基础系统主要由litemall数据库、litemall-db模块和litemall-os-api模块组成。 目前litemall基础系统主要由litemall数据库、litemall-db模块和litemall-os-api模块组成。
## 2.1 litemall数据库 ## 2.1 litemall.sql
litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/nideshop/blob/master/nideshop.sql)数据库,然后在实际开发过程中进行了调整和修改: litemall.sql数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/nideshop/blob/master/nideshop.sql)数据库,然后在实际开发过程中进行了调整和修改:
* 删除了一些目前不必要的表; * 删除了一些目前不必要的表;
* 删除了表中一些目前不必要的字段; * 删除了表中一些目前不必要的字段;
...@@ -32,7 +32,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni ...@@ -32,7 +32,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
因此采用独立的商品参数表,通常是商品的一些公共基本商品参数; 因此采用独立的商品参数表,通常是商品的一些公共基本商品参数;
商品规格表是商品进一步区分货品的标识,例如同样一款衣服,基本信息一致,基本属性一致,但是在尺寸这个属性上可以 商品规格表是商品进一步区分货品的标识,例如同样一款衣服,基本信息一致,基本属性一致,但是在尺寸这个属性上可以
把衣服区分成多个货品,而且造成对应的数量和价格不一致。 把衣服区分成多个货品,而且造成对应的数量和价格不一致。商品规格可以看着是商品属性,但具有特殊特征。
商品规格和规格值存在以下几种关系: 商品规格和规格值存在以下几种关系:
...@@ -41,7 +41,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni ...@@ -41,7 +41,7 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
* 多个规格和单一规格值,可以简化成第一种情况,或者采用第四种情况,通常实际情况下不常见; * 多个规格和单一规格值,可以简化成第一种情况,或者采用第四种情况,通常实际情况下不常见;
* 多个规格和多个规格值,通常是两种规格或者三种规格较为常见,而且对应的价格不完全相同。 * 多个规格和多个规格值,通常是两种规格或者三种规格较为常见,而且对应的价格不完全相同。
货品则是最终面向用户购买的商品标识,存在数量和价格两种属性 货品则是最终面向用户购买的商品标识,存在多个规格值、数量和价格。
因此这里一个商品表项,存在(至少0个)多个商品属性表项目,存在(至少一个)多个商品规格表项, 因此这里一个商品表项,存在(至少0个)多个商品属性表项目,存在(至少一个)多个商品规格表项,
存在(至少一个)多个货品表项。 存在(至少一个)多个货品表项。
...@@ -80,13 +80,18 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni ...@@ -80,13 +80,18 @@ litemall数据库基于nideshop中的[nideshop.sql](https://github.com/tumobi/ni
以下是一些细节的讨论: 以下是一些细节的讨论:
* 商品表中可能存在数量和价格属性,而货品中也存在数量和价格属性, * 商品表中可能存在数量和价格属性,而货品中也存在数量和价格属性,目前设计这样:
但是商品表中的数量和价格应该仅用于展示,而不能用于最终的订单价格计算。 * 商品表的价格应该和某个货品的价格一样,通常应该是所有货品价格的最小值,或者基本款式的价格;
商品表的数量应该是所有货品数量的总和。 * 商品表中的数量和价格应该仅用于展示,而不能用于最终的订单价格计算;
商品表的价格应该和某个货品的价格一样,通常应该是所有货品价格的最小值。 * 商品表的数量应该设置成所有货品数量的总和;
因此这里商品表的数量和价格属性可能可以采用自动计算。 * 在管理后台添加商品时,如果管理员不填写商品表的数量和价格属性,则自动填写合适的值;如果填写,则使用显示。
* 当小商城中,用户查看商品详情时,初始显示商品表的价格,而如果用户选择具体规格后,则商品
详情里面的价格需要自动切换到该规格的价格。
* 商品规格可以存在规格图片,效果是规格名称前放置规格图片 * 商品规格可以存在规格图片,效果是规格名称前放置规格图片
* 货品也可以存在货品图片,效果是所有规格选定以后对应的货品有货,则在货品价格前放置货品图片 * 货品也可以存在货品图片,效果是所有规格选定以后对应的货品有货,则在货品价格前放置货品图片
* 如果商品是两种规格,分别是M个和N个规格值,那么通常应该是`M*N`个货品,但是有些货品可能天然不存在。
那么,此时数据库如何来设计,是允许少于`M*N`个项,还是必须等于`M*N`个,而不存在货品的数量设置为0?
*
注意: 注意:
......
# 4 litemall后台管理 # 4 litemall管理后台
这里的后台管理业务参考了[platform](https://gitee.com/fuyang_lipengjun/platform). 这里的后台管理业务参考了[platform](https://gitee.com/fuyang_lipengjun/platform).
技术架构: 目前管理后台的设计存在一个关键问题:
* 是允许管理员拥有最大权限,直接对数据库内的数据进行任何CRUD操作;
好处是:
* 管理员可以伪造一些数据、篡改一些数据。。。
* 维护成本低,不会因为业务调整而需要调整管理后台代码
* 开发快,不需要设计具体的后台操作业务。
坏处是:
* 安全低,万一管理员密码泄露,用户可以得到所有数据。
* 管理员操作数据,需要对数据关系有一定的了解。
如果操作不当,可能造成数据关系混乱,甚至系统崩溃。
* 还是仅允许管理员按照所设计的业务只能操作部分数据。
好处是:
* 安全高,用户在设计好的业务下不会破坏后台数据。
如果密码泄露,带来的损失相对前者较小。
* 操作性好,
坏处是:
当然从项目本身来说后者应该更实际,但是对于小型用户来说,
前者的好处也是存在的。
目前本项目开发方案是第一种,在后面开发阶段(例如v2.0.0)应该会切换到第二种。
项目技术架构:
* 后台管理前端,即litemall-admin模块 * 后台管理前端,即litemall-admin模块
* vue * vue
...@@ -17,12 +47,14 @@ ...@@ -17,12 +47,14 @@
* Spring Boot 1.5.10 * Spring Boot 1.5.10
* Spring MVC * Spring MVC
目前发现存在的一些问题: 目前存在的问题:
* `严重`富文本编辑器 * `严重`富文本编辑器
* `严重`业务功能重新设计,例如即使是管理员也不能删除修改用户的相关数据 * `严重`业务功能重新设计,例如即使是管理员也不能删除修改用户的相关数据
* `严重`进一步区分商品和货品的关系 * `严重`进一步区分商品和货品的关系
* `严重`商品和货品管理,特别是添加一个商品 * `严重`商品和货品管理,特别是添加一个商品
* `缺失`支持微信登录
* `缺失`后台采用事务
* `缺失`用户密码加盐存储 * `缺失`用户密码加盐存储
* `缺失`首页中实现一些小组件,同时点击能够跳转相应页面 * `缺失`首页中实现一些小组件,同时点击能够跳转相应页面
* `缺失`商品评价中管理员回复功能 * `缺失`商品评价中管理员回复功能
...@@ -35,7 +67,13 @@ ...@@ -35,7 +67,13 @@
* `改善`地址优化,目前每一次点击都会请求后台,应该缓存已有的数据 * `改善`地址优化,目前每一次点击都会请求后台,应该缓存已有的数据
* `改善`查询时排序功能 * `改善`查询时排序功能
* `改善`vue和vue-element-admin等及时更新 * `改善`vue和vue-element-admin等及时更新
* `未来`管理员角色和权限设计 * `功能`系统角色和权限
* `功能`系统日志功能
* `功能`系统数据字典功能
* `功能`系统栏目管理功能
* `功能`支持国际化???
* `功能`支持数据库备份
## 4.1 litemall-admin-api ## 4.1 litemall-admin-api
...@@ -50,6 +88,36 @@ ...@@ -50,6 +88,36 @@
litemall-admin模块的代码基于[vue-element-admin](https://github.com/PanJiaChen/vue-element-admin) litemall-admin模块的代码基于[vue-element-admin](https://github.com/PanJiaChen/vue-element-admin)
### 4.2.1
### 4.2.2
### 4.2.3
### 4.2.4
### 4.2.5
### 4.2.6
### 4.2.7
### 4.2.8
### 4.2.9
### 4.2.10 系统基础功能
#### 4.2.10.1 数据字典
#### 4.2.10.2 角色权限
#### 4.2.10.3 国际化
#### 4.2.10.4 菜单
#### 4.2.10.5 日志
## 4.3 开发新组件 ## 4.3 开发新组件
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment