xtoon-cloud
基于畛域驱动设计(DDD)并反对 SaaS 平台的微服务开发框架.
码云源码:https://gitee.com/xtoon/xtoon-cloud
官网 |
在线体验 |
前端开源框架 |
为何抉择 xtoon-cloud
- 解决编写过程式和事务代码,造成前期保护逻辑凌乱、保护老本高的痛点;
- 边界标准易维持,外围业务逻辑内聚在畛域内,低耦合,高内聚,易于长期保护;
- 网上根本讲的都是 DDD 的实践很少有讲怎么落地,xtoon-cloud 提供了残缺落地计划和企业级微服务架构;
- 能够疾速开发,框架提供了系统管理和组织架构等外围模块;
- 反对多租户的 SaaS 平台;
技术交换
如果有什么问题或倡议能够 提 ISSUE 或 加群(QQ:130950009),交换技术,分享教训。
如果你解决了某些 bug,或者新增了一些性能,欢送 奉献代码,感激不尽~
大家多点 ⭐Star 反对下。
技术选型
- 根底框架:Spring Cloud Alibaba
- 网关:Spring Cloud Gateway
- 鉴权认证:Spring Cloud Security+JWT
- 服务监控:spring-boot-admin
- 流量管制:Sentinel
- 注册配置核心:Nacos
- RPC:dubbo
- mybatis-plus
次要模块
- 登录注册:账号、手机号验证登录,租户注册;
- 用户治理:用户新增,调配角色,禁用等;
- 角色治理:角色新增,查看,保护菜单等;
- 菜单治理:树形菜单治理,可配置菜单和按钮权限等;
- 租户治理:租户列表,禁用等;
- 日志治理:记录操作日志记录和查问;
我的项目构造
xtoon-could
├──doc 文档
│ ├─db sql
│ └─yaml 配置文件
│
├─xtoon-common 公共模块
│ ├─xtoon-common-core 外围公共模块
│ ├─xtoon-common-log 日志公共模块
│ ├─xtoon-common-mybatis mybatis 公共模块
│ ├─xtoon-common-redis redis 公共模块
│ ├─xtoon-common-swagger swagger 公共模块
│ ├─xtoon-common-tenant 多租户公共模块
│ └─xtoon-common-web web 公共模块
│
├─xtoon-ops 运维服务
│ ├─xtoon-auth-server 认证服务
│ ├─xtoon-gateway-server 网关
│ ├─xtoon-monitor-server 衰弱监控服务
│ ├─xtoon-register-server 注册配置核心
│ └─xtoon-sentinel-server 流量管制
│
├─xtoon-service 业务服务
│ └─xtoon-sys 系统管理畛域
│ ├─xtoon-sys-interface 系统管理接口
│ └─xtoon-sys-server 系统管理服务
│
部署
部署形式
- 拉取前后端我的项目代码;
- 装置必要的环境:jdk1.8+,mysql5.7+,redis,nodejs 等;
- mysql 新建两个库,导入 doc 上面的 sql 文件;
- 批改老本地环境配置:mysql,redis;
- 启动前后端我的项目,拜访地址;
启动程序
- xtoon-register-server(注册配置核心)
- xtoon-sys-server(用户服务)
- xtoon-auth-server(认证服务)
- xtoon-gateway-server(网关服务)
- xtoon-monitor-server(监控服务)
- xtoon-sentinel-server(流量管制服务)
- xtoon-could-element(前端我的项目)
核心理念
六边形实践
Alistair Cockburn 提出了六边形架构,又被称为端口和适配器架构。察看上图咱们发现,对于外围的应用程序和畛域模型来说,其余的底层依赖或实现都能够形象为输出和输入两类。组织关系变为了一个二维的内外关系,而不是高低构造。每个 io 与应用程序之前均有适配器实现隔离工作,每个最外围的边都是一个端口。基于六边形架构设计的零碎是 DDD 谋求的最终状态。
数据驱动和畛域驱动比照
畛域驱动设计与之前的零碎设计开发过程有很大的不同:
- 就在于零碎的参加角色,产品、开发、测试等,须要造成一套通用语言;
- 在于方案设计不再把 db 设计放在一个外围问题去解决,更加专一于业务模型自身,进行畛域、业务聚合的设计,畛域层的聚合及实体才是整个零碎的核心内容;
- 真正的面向对象编程,由过程式的事务脚本形式,转变为真正的面向对象。
分层架构
- 用户界面层 (或表示层)
负责向用户显示信息和解释用户指令。这里指的用户能够是另一个计算机系统,不肯定是应用用户界面的人 - 应用层
定义软件要实现的工作,并且指挥表白畛域概念的对象来解决问题。这一层所负 责的工作对业务来说意义重大,也是与其余零碎的应用层进行交互的必要渠道
应用层要尽量简略,不蕴含业务规定或者常识,而只为下一层中的畛域对象协调 工作,调配工作,使它们相互合作。它没有反映业务状况的状态,然而却能够具备 另外一种状态,为用户或程序显示某个工作的进度 - 畛域层 (或模型层)
负责表白业务概念,业务状态信息以及业务规定。只管保留业务状态的技术细节 是由基础设施层实现的,然而反映业务状况的状态是由本层管制并且应用的。畛域 层是业务软件的外围 - 基础设施层
为下面各层提供通用的技术能力: 为应用层传递音讯,为畛域层提供长久化机制,为用户界面层绘制屏幕组件,等等。基础设施层还可能通过架构框架来反对 4 个档次 间的交互模式