一、微服务搭建思路
大家看到的这张架构图并不是空穴来潮，它是通过不断演变出来的，我们要从DDD四层架构、微服务架构两个维度去融合理解。
这里的DDD四层架构适用于单个服务的工程架构（如图中的左下部分），就是单体应用的DDD四层架构的包划分方式。
而微服务架构，则是从整体去看，整合多个单体应用，它们之间通过应用SDK工程进行RPC通讯。
二、微服务架构下的应用SDK
这个工程比较好理解，类似于我们传统的理解的RPC包，或者叫API包，在Maven工程里，一般定义为一个子Module，里面主要定义的是Feign接口（如service.XxxFeignService），DTO对象（contract.dto.XxxRequest/XxxResponse）等等，此外还可以对FeignService返回的数据进行清洗与简单通用的封装（如util.XxxUtil），也就是说它还能封装简单的业务逻辑。
但需要特别注意：应用SDK要往一个大尺度独立的聚合工程的方向去搭建，它里面的顶层包要按内部业务系统的维度去隔离，并且它和业务系统不是一对一的关系。
为什么要这样设计？我讲个例子你就明白了。
我们公司的业务系统在顶层划分为SaaS应用和PaaS应用，那么PaaS应用对应的应用SDK可以命名为PaaSSdk，在PaaSSdk工程里，包括了消息中心、ChatAI、应用市场等PaaS应用的外部接口封装与简单业务逻辑封装。
这样做的好处显而易见——SaaS应用需要用到PaaS应用的接口时，只需要引入PaaSSdk即可，原则上这个内部Sdk与我们平时引入的外部Jar包没什么区别，可能只是网关和鉴权体系不一样罢了。
而且，简单的业务系统就用一个module就好了，没必要再拆分多个module，要知道，每引入多一个东西就有更多的不确定性。
所以你也就能理解，为什么这里的应用Sdk与业务系统不是一对一的关系，如果是一对一，业务系统势必要引入大量的Jar包，这在维护成本上是个灾难。试想一下，如果要用到阿里云OSS的Jar包时，你会引入大量POM吗？
三、DDD四层架构下的业务工程
DDD建模与落地的这几年，收获了不少好评，也着实为业务成功做出了贡献，优化了大半年，如今终于可以跟大家正式见面了。
先谈架构思想：
- 经典DDD四层架构：作为主要骨架，其他优秀架构思想作指导
- 整洁架构思想：应用到DDD领域层与基础设施层，接口与实现拆到不同层，把技术代码与业务代码分离
- 菱形架构思想：内部以领域层的领域模型为核心，向南北两个方向发散
- D3boot基础框架：作为基础设施，提供基础CRUD接口、BOM依赖等基础封装，应用在各层，简化链接，是快速搭建应用SDK、业务系统的粘合剂
DDD四层架构说明：
- 接入层：对外提供的系统入口/接口，如放Controller类，并按端划分（这里的client包写移动端接口，admin包写管理端接口，open包写开放接口）
- 应用层：跨聚合的服务编排service.XxxAppService、跨聚合领域事件监听event.XxxListener，实体工厂factory.XxxFactory
- 领域层：定义核心业务规则，与具体技术无关，不依赖其他各层；服务内按领域聚合划分，外部聚合external.xxx按限界上下文（微服务）划分；model定义充血模型、值对象，repository定义仓库接口，service定义聚合内的领域服务，event定义聚合内的领域事件监听器；领域契约contract包含：API层特殊出入参dto.XxxRequest/dto.XxxResponse、数据查询参数param.XxxParam、领域事件event.XxxEvent
- 基础设施层：具体技术相关的代码/框架、仓库层实现repository.impl.XxxRepositoryImpl，包括数据聚合实现（fill方法）；external放外部服务实现，做接口防腐
四、集成D3boot基础框架
领导让你搭个业务系统，如果什么都从零开始的话，项目周期就太长了。我们在搭建系统的过程中，如果有这么一个框架，能够快速解决CRUD、工程结构划分等等问题就好了。
D3boot基础框架的出现，正是为了解决这个问题。一般SpringBoot只能集成Spring体系内的技术栈，但作为心态更开放的我们，不应把目光聚焦在Spring体系内，每家企业都应该有自己的基础框架。
D3boot，意为DDD工程快速启动，其中融入了DDD领域驱动的架构思想，并且能处处体现充血模型带来的CRUD上的便利，还支持SaaS应用的搭建（租户隔离）。D3boot框架旨在快速搭建SaaS业务系统，减少繁琐的CRUD定义，减少不必要的xml代码书写。
充血模型的思想体现在对Model的继承，即可实现你想要的CRUD；而通过领域工厂（Factory的build、convert、fill等方式），又可以利用贫血模型思想的优势，对复杂的对象进行构建、转换、填充，弥补了充血模型的不足。
目前我已使用这套轻量级微服务基础框架，在公司里的健康管理平台、消息中台、工单中台、社交中台、ChatAI等业务系统应用了起来，使用感受一个字：舒服。
而作为基础框架，考虑的更多是不同框架集成的问题、功能边界问题，接下来我给大家一一介绍。
以下是D3boot的结构：
1.base：基础组件
可扩展的基础组件，下面包括多个子模块，包括：
base-core：基础核心组件：
定义了基础核心上下文（如SpringContext、ThreadContext、BaseContext）、核心契约（如R对象、Page对象、抽象领域事件、业务异常、统一状态码等）、核心工具类（如Bean转换工具、Json转换工具、业务断言工具等）。
base-data：基础数据组件：
定义了基础模型（支持CRUD的充血模型）、基础仓库及MybatisPlus的仓库实现、数据类型处理器等，支持通过@TenantId注解PO类租户字段来隔离租户数据等。用到数据库的工程需要依赖此包。
base-mq：基础MQ组件：
目前集成了Kafka消息队列，可快速通过注解方式实现MQ消费。
base-kit：基础工具箱：
工具类，底下按不同的能力又细分为缓存类、事件类、语言类、线程类、WEB类工具。
base-monitor：基础监控组件：
集成HealthCheck接口、启动打印代码版本功能、日志告警功能（能把log.error的日志告警到企微机器人/钉钉机器人）。
base-web：基础WEB组件：
定义了CRUD控制器基类CRUDController、按端划分的模型控制器接口ModelController、全局异常增强、全局R对象包装、全局Feign异常降级、各类WEB拦截器、基础接口认证功能等。WEB工程需要依赖此包。
2.base-bom：基础依赖组件
Maven的BOM（Bill of Materials）机制是Maven项目中的一个重要概念，它用于管理项目的依赖关系和版本控制。BOM机制可以帮助开发人员快速构建和维护项目，并且可以确保项目的稳定性和可靠性。
Spring有自己的bom文件，如spring-boot-dependencies，里面定义了构建SpringBoot工程所需要的依赖。
参考Spring的方式，我们把第三方的依赖统一在base-bom组件里进行管理，这样一来，业务工程只需要引入对应的dependency即可（包括定义D3boot框架里的组件版本），不需要再在业务系统过多地指定用哪个版本，达到版本统一的效果。
3.base-contract-parent：业务Contract父工程组件
作为应用SDK工程的父POM，快速搭建应用SDK。
4.base-parent：业务父工程组件
作为业务工程的父POM，快速搭建业务系统。
5.ddd-demo：DDDDemo工程
基于D3boot框架搭建的DDD四层架构风格的业务工程，写得比较粗糙，具体参考架构图的实现为准。
五、写在最后
我一直认为，基础框架不能写得太重，公司的公共组件不应放在基础框架工程内实现，而是另外定制。在基础框架的开发过程中，我不断汲取前辈的优秀代码经验，并融入自己的代码特色，提炼高复用性代码，并对中间件进行浅封装。
此外，本着技术开放的心态，这套基础框架决定走开源路线，大家可以下载Deploy到自己的私仓使用，基于自己公司的业务进一步定制自己的基础组件。
Gitee源码地址：https://gitee.com/jensvn/d3boot（例行赊Star）
D3boot基础框架具体的使用方式见源码的README.md文件，这里不再赘述。
