# 漫步商城

**Repository Path**: darky_king/manbu

## Basic Information

- **Project Name**: 漫步商城
- **Description**: 基于DDD领域驱动模型构建的企业级商城项目
- **Primary Language**: Java
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2024-12-03
- **Last Updated**: 2024-12-03

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

基于DDD领域驱动模型构建的企业级聚合项目 manbu
基于DDD领域驱动设计思想创建维护的支持单体及微服务的企业级应用开发脚手架，具有商城应用服务模块，社区应用服务模块，出游任务应用服务模块等；
领域服务：用户中心服务，积分服务，支付服务等领域中台服务；项目集成多位生产一线开发者的企业应用构建运维经验，
支持单体jar包，docker容器化，k8s集群等方式部署


严格的设计规范是一个项目持续健壮的基础保障，不仅可以减少项目延续的沟通成本，在熟练后还能大大提高开发效率和系统稳定性。

数据库规范：
1、表内必要字段且不可为空，避免字段关键字冲突

|  字段名  | 类型           | 长度 | 备注              |
|  :----  |--------------|----|-----------------|
| id  | int          | 10 | 主键Id            |
| data_version  | int          | 10 | 版本号             |
| gmt_create  | datetime     |    | 创建时间            |
| gmt_modify  | datetime  |    | 更新时间            |
| del_flag  | int          | 1  | 逻辑删除标记 0未删除，1删除 |
| stop_flag  | int          | 1  | 停用标记 0未停用，1停用   |

2、表名设计 

1）、 表名以 t_ 开头
2）、 日志表 _log 结尾
3）、 备份表 _bak 结尾
4）、 临时表 _temp 结尾
5）、 配置表 _config 结尾




Interface层的HTTP和RPC接口，返回值为Result，捕捉所有异常
Application层的所有接口返回值为DTO，不负责处理异常

一个Interface层的类应该是“小而美”的，
应该是面向“一个单一的业务”或“一类同样需求的业务”，需要尽量避免用同一个类承接不同类型业务的需求。
接口遵循单一职责原则，每个接口需要有完整的传递链

由于大部分项目要求只用POST和GET,无法完整实现Restful接口格式，故将crud放在接口路径里，
接口路径中要提现出CRUD  add(create)   get(read)   up(update)   del(delete)


涉及到三方对接的状态信息每个节点都要落库状态，这样便于排查问题

对于存库数据，主键用int或者long类型，其他字段除日期类型外，其他都用string,方便代码逻辑统一处理，避免过多类型转换的不统一

接口层所有参数放在param包下，所有提供给web访问的实体放在vo包下，名称根据接口方法名+Param或接口方法名+Vo命名

interface层关注返回状态和异常处理，application层只关注领域服务编排逻辑

application 层方法名称定义 动词如 add(create)   get(read)   up(update)   del(delete) + 名词（一般为返回的实体名称，如token, verifyCode）,
如果接口还做了其他操作，则还要with + 场景，如：getTokenWithLogin

理论上的DDD领域驱动模型分为四层：领域模型、应用服务、接口层、数据访问层，
按照代码组织结构，数据访问层放在最底层（基础中间件配置，通用工具类，对应领域层的持久化接口）
但在实际业务场景中，针对不同的领域服务，基础中间件配置，通用工具类是所有层都需要的，因此应该独立成包放在最底层，
而持久化接口是领域紧密相关的，而且仓储层的实现放在基础层会导致聚合根等实体要引入到基础层更加增加了耦合性，应该放在agg领域层进行统一管理
而且又由于实际项目场景中，对于中小型公司（千万用户级）服务都是业务整理进行拆分，不可能拆分粒度过于精细（业务复杂度和服务治理都会带来问题）
因此在领域层，只有像用户中心，积分服务，支付服务，定时任务这类通用服务才适合独立服务拆分，像其他如商城，社区等服务则各自完整作为独立服务拆分
这些领域服务共同构成整个项目的中台服务体系,agg配套提供对应的facade层，便于解耦，提供应用层的接口访问

对于接口层主要实现的是提供接口开放和统一异常处理以及认证鉴权，相对扁平，为了避免服务过度拆分，可以合并到应用服务层，即bff层，
因此针对例如商城服务，可以创建一个app-bff(提供app和小程序接口)和一个admin-bff（后台管理的接口），
当然，如果商城，社区等服务是整合在同一个app中，也可以将多个对应app-bff整合在一起，admin-bff同理

这样DDD的基础四层结构在保证灵活运维的基础上进行了拆分重组，也保证了业务逻辑的清晰和可维护性

独立提供gateway模块用于统一接口认证鉴权，限流，日志记录等，更重要的是可以实现开发阶段的路由转发，有利于提升开发效率

独立adapter服务用于适配第三方接口，如短信，第三方支付等

独立openapi服务用于对外发布接口，如开放平台，对外发布接口，便于后续接入方接入

如果要拆分微服务，只需要把agg结尾模块和bff结尾模块以及adapter,open,gateway几个模块创建启动类即可

数据库映射对象不能出仓储层，仓储层专注于与数据存储相关的操作，UserModel作为仓储层的一个数据结构，可以确保数据库操作的逻辑独立于业务逻辑。
随着项目的发展，如果数据库模型发生变化，只需在仓储层进行修改，而不会影响到领域层。

User聚合根其实是以用户为核心，聚合根里面的值对象都是用户相关的属性，如一个人有多个地址（地址包括地址明细和地址编号），那么在User聚合根里就应该有一个地址实体List
聚合跟，顾名思义就是以此为跟进行的聚合和延展
聚合根是整个领域的核心类，值得花费经历维护


分层分工有一个原则，如果某段逻辑是所有bff通用，那么就要下沉到对应agg,如果是当前bff唯一使用，那么就放当前bff

采用多业务拆分多库的设计：
性能优化：用户管理模块和订单管理模块可以分别优化，减少锁竞争。
可维护性：每个模块都可以独立维护和升级，不影响其他模块。
安全性：支付管理模块可以设置更高的安全级别，保护敏感数据。
扩展性：可以独立扩展各个模块的数据库，应对高并发场景。
备份与恢复：每个模块可以独立备份和恢复，简化操作流程。

微服务后期要通过k8s进行部署关联，k8s专注服务容器管理，微服务网关还是采用gateway实现，入口通过nginx 访问可以连通的k8s集群ip进行访问

注册中心和配置中心通过nacos实现

如果实现单体服务，将各个服务模块启动类上的注解注释，并将父pom里的nacos-discovery和nacos-config的依赖注释掉即可

反之微服务则需要放开将父pom里的nacos-discovery和nacos-config的依赖，并恢复各个子模块启动类的注解


AGG服务  端口 9970开始

GATEWAY  和  单体START  9980端口
其他微服务 9981开始

涉及技术点：
1. 分布式锁 **
2. 链路追踪传递 ****
3. 多层调用统一异常处理 ****
4. 分层服务调用（领域中台）*****
5. 多数据源 **
6. uidgenerator 分布式id生成(百度开源) **
7. nacos 注册中心 + 配置中心 **
8. spring cloud gateway 网关 + nacos 动态路由 **


项目结构说明：
## 独立服务模块
### adapter 聚合所有三方调用
### gateway 统一网关
### open 聚合所有对外接口
### start 单体服务启动入口
### common 基础依赖包（包含通用配置和工具类）

## BFF层（每个完整业务整合一个BFF服务模块，如商城，社区）
### community-admin-bff 社区后台应用层+接口层
### community-app-bff 社区app应用层+接口层
### mall-admin-bff 商城后台应用层+接口层
### mall-app-bff 商城app应用层+接口层
### travel-admin-bff 出游任务后台应用层+接口层
### travel-app-bff 出游任务app应用层+接口层

## AGG层（通用聚合根，聚合根实现，仓储接口，仓储实现，如用户中心，积分中心，支付中心等）
### user-agg 用户，鉴权，系统配置领域服务+仓储逻辑层
### user-agg-facade 用户和鉴权领域服务对外暴露接口


哪些可以聚合：
用户+鉴权+用户组（org）
角色+菜单+权限
圈子+主题+帖子+评论+回复
积分+积分规则+积分记录
订单+订单规则+订单记录
优惠券+优惠券规则+优惠券记录
活动+活动规则+活动记录
支付+支付方式+支付规则+支付记录
系统配置
消息中心+短信，邮件，通知（站内信+推送）
IM

注意实体不跨层原则，Model实体只在领域层使用，AGG层使用req,resp,dto, BFF引用req,resp,使用Vo，param