开源地址：https://gitee.com/xtoon/xtoon-boot
官网：http://xtoon-boot.xiangtoon.com
在线演示：http://xtoon-boot.demo.xiangtoon.com
如果有什么问题或建议可以加群（QQ：130950009），交流技术，分享经验。
微服务版xtoon-cloud（推荐）：https://gitee.com/xtoon/xtoon-cloud
为何开源
项目初期或MVP阶段建议用DDD的单体框架开发应用，后期根据领域的不同弹性需求是再改造成微服务版。
个人不建议开始就上微服务，服务拆分的很细，这只会增加开发成本和风险，个人认为应该选择合理的框架和方案，确保后期能快速的、低成本的从单体过度为微服务。
这正是我们开源基于DDD的xtoon框架的初衷，目前单体应用版和微服务版都已发布正式版，希望给践行DDD和微服务的开发者们带来一些价值，谢谢！
为何选择xtoon-boot
- 解决编写过程式和事务代码，造成后期维护逻辑混乱、维护成本高的痛点；
- 抛弃MVC框架，拥抱更适合复杂业务的开发框架；
- 网上基本讲的都是DDD的理论很少有讲怎么落地，xtoon-boot提供了完整落地方案和实践；
- 可以快速开发，框架提供了系统管理和组织架构等核心模块；
- 支持多租户的SaaS平台；
为何开源
工作中一直有个困恼：为什么身边很多项目后期维护时业务逻辑变的混乱不堪，service层代码变的庞大难以修改，维护成本也越来越高，有没有好的解决方式的？
后来接触到Eric Evans的DDD（Domain-Driven Design 领域驱动设计），发现这正是为了解决复杂业务而提出的思想。 但后来并没找到一套基于DDD应用的开源框架，因此决定自己从0开始投入研发。
现在1.0版本终于上线了，我们把这套框架开源出来想跟大家探讨并一起维护，希望今后有更多的项目和产品能使用这套框架。
技术选型
- Springboot
- Apache Shiro
- Mybatis-plus
- Alibaba Druid
- Element-ui
主要模块
- 登录注册：账号、手机号验证登录，租户注册；
- 用户管理：用户新增，分配角色，禁用等；
- 角色管理：角色新增，查看，维护菜单等；
- 菜单管理：树形菜单管理，可配置菜单和按钮权限等；
- 租户管理：租户列表，禁用等；
- 操作日志：系统操作日志记录和查询；
项目结构
xtoon-boot
├─db 数据库SQL脚本
│
├─xtoon-common 公共模块
│ │
│ └─java
│ ├─domain 领域通用类
│ └─util 工具类
│
├─xtoon-api 接口模块
│ │
│ ├─java
│ │ ├─common 接口通用类
│ │ ├─util 接口工具类
│ │ └─web controller类
│ └─resources
│ ├─static.swagger swagger文件
│ ├─application.yml 全局配置文件
│ └─logback-spring.xml 日志配置文件
│
├─xtoon-sys 系统子域模块
│ │
│ └─java
│ ├─application 应用层
│ │ └─impl 应用接口实现
│ ├─domain 领域层（核心）
│ │ ├─factory 工厂
│ │ ├─model 领域模型
│ │ ├─repository 资源接口
│ │ ├─service 领域服务
│ │ ├─specification 规格校验
│ │ └─external 外部接口（防腐层）
│ ├─infrastructure 基础设施层
│ │ ├─repository mybatis持久化类（应该都熟悉就不展开了）
│ │ └─external 外部服务类
│ └─facede 门面类层
│ ├─assembler DTO转换类
│ ├─dto DTO
│ └─impl 门面类
│
├─xtoon-org 组织架构子域模块
│
核心理念
六边形理论
Alistair Cockburn提出了六边形架构，又被称为端口和适配器架构。观察上图我们发现，对于核心的应用程序和领域模型来说，其他的底层依赖或实现都可以抽象为输入和输出两类。组织关系变为了一个二维的内外关系，而不是上下结构。每个io与应用程序之前均有适配器完成隔离工作，每个最外围的边都是一个端口。基于六边形架构设计的系统是DDD追求的最终形态。
数据驱动和领域驱动对比
领域驱动设计与之前的系统设计开发过程有很大的不同：
- 就在于系统的参与角色，产品、开发、测试等，需要形成一套通用语言；
- 在于方案设计不再把db设计放在一个核心问题去解决，更加专注于业务模型本身，进行领域、业务聚合的设计，领域层的聚合及实体才是整个系统的核心内容；
- 真正的面向对象编程，由过程式的事务脚本方式，转变为真正的面向对象。
分层架构
- 用户界面层(或表示层)
负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统， 不一定是使用用户界面的人 - 应用层
定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负 责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道
应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调 任务，分配工作，使它们互相协作。它没有反映业务情况的状态，但是却可以具有 另外一种状态，为用户或程序显示某个任务的进度 - 领域层(或模型层)
负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节 是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域 层是业务软件的核心 - 基础设施层
为上面各层提供通用的技术能力:为应用层传递消息，为领域层提供持久化机制， 为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持4个层次 间的交互模式
