文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载导读本文以 CodeGuide 仓库 DDD 系列路书中的《DDD 工程模型》为核心讲解在分布式微服务架构下为什么 MVC 的Service 贫血模型结构会让工程越来越混乱以及六边形架构、整洁架构、洋葱架构等 DDD 分层模型如何将异常处理、数据库连接、日志、外部服务调用、消息监听、任务轮询等科目优雅地安置到对应工程模块。读者读完后将掌握 DDD 工程的分层结构设计、领域模型model/repository/service的拆分方法、分层调用链路中各层对象entity、valobj、aggregate、po、dto、response的职责边界以及一个可运行的 DDD 多模块工程xfg-frame-ddd的完整搭建与测试验证方案。本文是 DDD 系列的第 3 节与 DDD 架构演进、DDD 概念理论、DDD 四色建模、DDD 架构设计 同属一个完整的学习脉络建议按序阅读。一、为啥需要架构MVC 装不下分布式技术栈说到开发代码为啥需要架构就像买了个房子为啥要隔出厨房、客厅、卧室、卫生间一样核心目的就是让不同的职责分配到不同的区域内。虽然代码里没有马桶要放卫生间、沙发要放客厅、床要放卧室这样的物理约束但工程开发中有一系列要引入的核心科目统一的异常处理数据库的连接日志的打印外部服务的调用消息的监听任务的轮询服务的实现这些内容都需要被分配到不同的工程包下承载。在 DDD 之前我们一直用 MVC 的分层结构承接这些内容。通用的、配置的、组件的、持久化的、内部的、外部的——在以往的单体应用时代并没有这么多东西那时的工程结构都偏向于Service 贫血模型。但随着微服务的演进越来越多的内容被填充到工程中。仔细审视原本的 MVC 结构会发现它已经变得非常混乱一个 Service 为了实现自己的功能要引入一大堆东西这些原子功能与 Service 自身的服务耦合在一块导致工程的维护成本越来越大。在Service 贫血模型的三层结构开发指导下没有细分出面向对象工程结构设计的区域划分所以通常意义的 MVC 下所有需要的内容都会堆砌到 Service 实现类中——就像老城区突然引入大量外来人口不知道怎么安置而 DDD 就像雄安新区做了整体规划。三层工程结构分配方式对于要承载庞大的分布式技术栈体系显然有点小马拉大车。凡是做到架构师岗位的都能推演出业务与技术的迭代发展中被动熵增与减熵增的博弈在架构层面分布式相比单体应用要额外引入非常多的技术栈而 MVC 并没有设计好如何安置它们。二、工程结构设计六边形、洋葱、整洁与菱形架构2004 年 Eric Evans 发表了《Domain Driven Design》著作2005 年 Alistair Cockburn 提出六边形关系图理论2008 年 Jeffrey Palermo 提出了洋葱架构。虽然这些架构并不是专门为 DDD 而出但巧合的是它们都在 DDD 一书发表之后陆续推出其分层设计方式与 DDD 非常契合在这些架构下可以很好地落地 DDD 设计方法。无论是六边形架构、洋葱架构还是张毅老师提到的南向网关/北向网关的菱形架构它们的共同目标都是以领域服务domain为核心隔离内部实现与外部资源的耦合。在 DDD 分层架构下各模块职责如下domain核心领域实现业务功能开发的主体infrastructure基础设施层承接对外部资源数据库、缓存、配置、外部接口的调用trigger触发器层向外部提供服务接口、消息、任务app应用启动层api接口定义层types通用信息层常量、结果包装、枚举case编排层可选用于较大项目的防腐与通用服务封装。在这样一套结构下各项开发科目可以被优雅地分配到各分层。相对于Service 数据模型的贫血模型结构现在以 domain 为核心开发业务功能不会在 domain 工程模块下引入各类外部组件可以更关心业务功能本身。将这套思想映射到工程中常见的分层结构有两套整洁架构与六边形架构。1. 整洁架构 - 工程结构整洁架构的分包形式会将所有的外部依赖使用和工程内要对外的统一定义到适配器层对外适配 对内适配。阿里的 cola 框架偏向整洁架构。2. 六边形架构 - 工程结构六边形架构会把本身提供到外部的接口调用、消息监听、任务调度统一放到trigger作为一个统一入口处理对于需要调用外部同类的能力数据库、缓存、配置、调用其他方的接口统一放到infrastructure基础设施层。从架构演进的角度看详见 DDD 架构演进工程分层经历了单层 → 三层 MVC → 三层分布式MVC export/rpc 等随意叠加→ 四层 DDD的演进。三层架构出现得很早本身没有考虑复杂的分布式场景各公司都是直接在旧工程里添加新的 module 分层模块导致工程结构很杂、装填了太多东西一个系统里 Service 上千个类每个类上千行代码。而六边形架构可以看作是专门为 DDD 做的配套架构它承接 DDD 对系统分析后的编码实现避免失去面向对象设计和编码的优势。三、领域模型设计充血结构与分包方式虽然大家用的都是 DDD也都有对应的模块和分包但在细节之处还是有差异。就像家里的衣物是所有家庭成员的衣服都放一起还是每个人有独立的衣柜只放自己的——这没有绝对的好坏分包需要按照最符合自己所需来设定。1. 分包方式两种主流分包方式方式 1DDD 领域科目类型分包——类型之下写每个业务逻辑如 model、repository、service 为顶层的包各业务都挂在其下方式 2业务领域分包——每个业务领域之下有自己所需的 DDD 领域科目如 order、rule、user 各自的包下都含 model、repository、service。例如一个工程下有用户、积分、抽奖、支付等业务紧凑的聚合类微服务有时候更易于维护方式 2 是拆分为独立的业务包方式 1 则是大家都在一个坛子里吃饭要啥去各个地方找。2. 领域模型DDD 领域驱动设计的中心主要在于领域模型的设计以领域所需驱动功能实现和数据建模。一个领域服务下面会有多个领域模型每个领域模型都是一个充血结构。一个领域模型 一个充血结构充血模型的具体解释可参考 DDD 概念理论 中的充血模型小节。一个领域模型中包含三个部分model模型对象定义含有 valobj VO、entity、Aggregateaggreate聚合对象实体对象、值对象的协同组织就是聚合对象entity实体对象大多数情况下实体对象Entity与数据库持久化对象PO是 1v1 的关系但为了封装一些属性信息也会出现 1vn 的关系valobj值对象通过对象属性值来识别的对象据《实现领域驱动设计》。repository仓储服务从数据库等数据源中获取数据传递的对象可以是聚合对象、实体对象返回的结果可以是实体对象、值对象。因为仓储服务是由基础层infrastructure引用领域层domain是一种依赖倒置的结构它可以天然地隔离 PO 数据库持久化对象被引用详见 DDD 架构设计 中领域分层的依赖关系说明。service服务设计这里要注意不要以为定义了聚合对象就把超越 1 个对象以外的逻辑都封装到聚合中这会让代码后期越来越难维护。聚合更应该注重和本对象相关的单一简单封装场景而把一些重核心业务放到 service 里实现。此外如果你的设计模式应用不佳那么无论是领域驱动设计、测试驱动设计还是换三层和四层架构工程质量依然会非常差。对象类型速查值对象/实体对象/聚合对象的定义与实现手段详见 DDD 概念理论值对象表示没有唯一标识的业务实体例如商品的名称、描述、价格等实体对象表示具有唯一标识的业务实体例如订单、商品、用户等聚合对象是一组相关的实体对象的根用于保证实体对象之间的一致性和完整性。关于 model 中各个对象的拆分尤其是聚合的定义会牵引着整个模型的设计。当然在初期使用 DDD 时不必过分在意领域模型的设计可以把整个 domain 下的一个个包当作充血模型结构这样编写出来的代码也非常适合维护。对象解释补充——DTO数据传输对象data transfer object。DTO 与业务对象或数据访问对象的区别是DTO 的数据变异子与访问子mutator 和 accessor、语法分析parser、序列化serializer时不会有任何存储、获取、序列化和反序列化的异常。即DTO 是简单对象不含任何业务逻辑但可包含序列化和反序列化以用于传输数据。四、分层调用链路各层对象的职责边界把 DDD 的分层架构平铺展开可以看到从一个接口的实现到各个模块分层中的调用链路关系。做代码开发时可以参考应该把什么功能分配到哪个模块中处理。从 APP 层、触发器层、应用层这三块主要对领域层的上下文逻辑封装、触发式MQ、HTTP、JOB使用并最终在应用层中打包发布上线。这一部分都是使用的处理不会有太复杂的操作。当进入领域层开始就是智力集中体现的开始所有对工程的抽象能力都体现在这一块区域。关于对象定义在六边形、整洁、COLA 等 DDD 架构下的使用场景domain 领域层entity实体对象如雇员用户的基本信息、订单信息、配送信息vovalue object值对象用于描述实体对象信息。如雇员用户的 level 枚举值对象、居住地址四级信息对象。这些对象不具有唯一性即不具有生命特征——就像你和你的衣服、你的胡子aggregate聚合对象当要写一笔订单入口时事务需要一组对象订单记录、账户记录、库存记录等这些实体对象 值对象被写入聚合对象内一起提交过去。以前的 MVC 下的 XxxVO、XxxReq、XxxRes现在被领域细分成各个模块下的实体、聚合、值对象了。infrastructure 基础设施层po数据库持久化对象用于映射数据库表字段。这个对象不要做业务流程只提供数据库数据dto数据传输对象用于与外部的接口对接。比如 rpc 接口、http 接口的出入参对象都叫数据传输对象命名为 XxxRequestDTO、XxxResponseDTO支付包的 SDK 包里就是这样命名的。api 层dto对象接口的出入参数据传输对象命名为 XxxRequestDTO、XxxResponseDTOresponse?对象包装结果对象提供 code、info、data准确描述错误码以及 data 数据。data 是泛型用于包装 XxxResponseDTO 结果。浏览器 F12 观察互联网 web 服务的接口就能看到这样的结构。case 编排层可选这一层承接 web 的接口编排动作串联 domain 领域流程。通常 2 个方案一个是直接引入 api 层定义的对象另一个是多一层转换在 case 层定义 api 层对应的 XxxRequestDTO → XxxRequest、XxxResponseDTO → XxxResponse 的转换。从更宏观的视角看DDD 架构设计整个调用可以抽象为触发 → 函数 → 连接分布式微服务的调用方式不只是 HTTP还包括 RPC 远程、MQ 消息、TASK 任务这些方式都可以理解为触发通过触发调用函数方法各个服务都可以当做一个函数方法来看函数方法通过连接调用其他接口、数据库、缓存来完成函数逻辑。这也是 DDD 常用于微服务场景的原因。五、工程架构案例xfg-frame-ddd 实战工程光讲理论很难落地需要一套可以直接上手的 DDD 工程。这里给出小傅哥的 xfg-frame-ddd 案例工程对应仓库 DDD 架构设计 中完整的 tree 树形图以及 DDD 工程脚手架 中脚手架化的搭建方式。1. 环境JDK 1.8Maven 3.8.6SpringBoot 2.7.2MySQL 5.7如果使用 8.0 记得更改 pom.xml 中的 mysql 引用Dubbomulticast 广播模式注册参考 Dubbo 官方文档的注册中心 multicast 说明2. 架构生成树形结构可安装brew install tree在 IntelliJ IDEA Terminal 中使用tree。整个工程的核心目录结构如下xfg-frame-ddd ├── pom.xml ├── xfg-frame-api # 接口定义IAccountService、IRuleService、model(request/response) ├── xfg-frame-app # 应用启动Application、aop(RateLimiterAop)、config、resources(yml/mybatis) ├── xfg-frame-domain # 领域封装order、rule、user 三个领域各含 model/repository/service ├── xfg-frame-infrastructure # 基础设施dao、po、repository 实现 ├── xfg-frame-trigger # 触发器http(Controller)、mq、rpc、task ├── xfg-frame-types # 通用类型Constants、Response └── docs # dev-ops(环境 docker-compose)、sql(road-map.sql)、xfg-frame-ddd.drawio整个工程由xfg-frame-app模块的 SpringBoot 驱动。domain 领域模型下提供了order、rule、user三个领域模块并在每个模块下提供了对应的测试内容。这块是整个模型的重点其他模块都可以通过测试看到调用过程。以 domain 模块为例各领域内部结构据源码树形结构为ordermodelaggregates/OrderAggregate、entity/OrderItemEntity、ProductEntity、valobj/OrderIdVO、ProductDescriptionVO、ProductNameVO、repository/IOrderRepository、service/OrderServicerulemodelaggregates/TreeRuleAggregate、entity/DecisionMatterEntity、EngineResultEntity、valobj/TreeNodeLineVO、TreeNodeVO、TreeRootVO、repository/IRuleRepository、serviceengine/EngineBase、EngineConfig、EngineFilter 及 impl/RuleEngineHandlelogic/BaseLogic、LogicFilter 及 impl/UserAgeFilter、UserGenderFilterusermodel/valobj/UserVO、repository/IUserRepository、service/UserService impl/UserServiceImpl。infrastructure 层的 daoIUserDao、RuleTreeDao、RuleTreeNodeDao、RuleTreeNodeLineDao与 poUserPO、RuleTreePO、RuleTreeNodePO、RuleTreeNodeLinePO以及 repository 实现UserRepository、RuleRepository恰好印证了仓储接口在 domain 定义、在 infrastructure 实现的依赖倒置设计。app 模块下的 application-dev.yml、application-test.yml、application-prod.yml 与 mybatis mapperRuleTree_Mapper.xml、RuleTreeNode_Mapper.xml、RuleTreeNodeLine_Mapper.xml则展示了分布式工程的资源配套。3. 领域一个领域模型中包含 3 个部分model 对象定义含有 valobj VO、entity、Aggregate、repository 仓储定义含有 PO、service 服务实现。这 3 个模块一般也是大家使用 DDD 时最不容易理解的分层。4. 环境开发 / 测试 / 上线通过 Maven profile 定义多环境切换。源码位于xfg-frame-ddd/pom.xmlprofile iddev/id activation activeByDefaulttrue/activeByDefault /activation properties profileActivedev/profileActive /properties /profile profile idtest/id properties profileActivetest/profileActive /properties /profile profile idprod/id properties profileActiveprod/profileActive /properties /profile除 pom 配置外还需要在xfg-frame-app的 application.yml 中指定激活环境spring: config: name: xfg-frame profiles: active: dev # dev、test、prod这样即可对应加载application-dev.yml、application-prod.yml、application-test.yml各个场景切换非常方便。5. 切面RateLimiterAop 限流实现一个工程开发中会有很多统一切面和启动配置的处理这些内容都可以在xfg-frame-app完成。源码位于cn.bugstack.xfg.frame.aop.RateLimiterAopSlf4j Aspect public class RateLimiterAop { private final long timeout; private final double permitsPerSecond; private final RateLimiter limiter; public RateLimiterAop(double permitsPerSecond, long timeout) { this.permitsPerSecond permitsPerSecond; this.timeout timeout; this.limiter RateLimiter.create(permitsPerSecond); } Pointcut(execution(* cn.bugstack.xfg.frame.trigger..*.*(..))) public void pointCut() { } Around(value pointCut(), argNames jp) public Object around(ProceedingJoinPoint jp) throws Throwable { boolean tryAcquire limiter.tryAcquire(timeout, TimeUnit.MILLISECONDS); if (!tryAcquire) { Method method getMethod(jp); log.warn(方法 {}.{} 请求已被限流超过限流配置[{}/秒], method.getDeclaringClass().getCanonicalName(), method.getName(), permitsPerSecond); return Response.Objectbuilder() .code(Constants.ResponseCode.RATE_LIMITER.getCode()) .info(Constants.ResponseCode.RATE_LIMITER.getInfo()) .build(); } return jp.proceed(); } private Method getMethod(JoinPoint jp) throws NoSuchMethodException { Signature sig jp.getSignature(); MethodSignature methodSignature (MethodSignature) sig; return jp.getTarget().getClass().getMethod(methodSignature.getName(), methodSignature.getParameterTypes()); } }使用方式在配置文件中添加限流配置例如permits-per-second: 1每秒 1 个许可、timeout: 5获取许可超时 5 毫秒# 限流配置 rate-limiter: permits-per-second: 1 timeout: 5实现要点解读RateLimiter.create(permitsPerSecond)基于 Guava RateLimiter 令牌桶切点execution(* cn.bugstack.xfg.frame.trigger..*.*(..))覆盖整个 trigger 触发层HTTP/MQ/RPC/TASK 统一入口实现全触发入口的统一限流限流被拒绝时通过xfg-frame-types模块的Constants.ResponseCode.RATE_LIMITER返回统一的Response包装结果——这也印证了上文api/types 提供 code、info、data 包装结果对象的分层职责。这样所有通用配置中与业务没有太大关系的部分就可以直接写到 app 层。六、工程测试验证整个工程由 SpringBoot 驱动测试验证步骤工程提供了road-map.sql测试 SQL 库表语句位于 docs/sql 下在本地 MySQL 上执行即可创建库表在 application.yml 中配置数据库连接信息打开 ApiTest 进行测试可以点击 Application 类的绿色箭头启动工程使用触发器trigger里的接口调用测试或者单元测试 RPC 接口也提供了泛化调用的方式。如果正常获取到预期的结果信息说明工程启动成功。之后就可以对照 DDD 的结构进行学习并使用这样的工程结构开发自己的项目。七、从工程模型到落地规范工程模型只是 DDD 落地的骨架要让骨架真正长出业务血肉还需要完整的方法论配套。仓库中的相关延伸资料可以按需阅读DDD 架构演进单层 → 三层 → 三层分布式 → 四层 DDD 的完整演进脉络DDD 概念理论充血模型、实体/值对象/聚合的定义特征与实现手段、仓储与适配器的依赖倒置解耦、领域编排与触发器DDD 四色建模从用例图出发通过事件风暴寻找领域事件、识别领域角色和对象、划分领域边界DDD 架构设计模块依赖关系与触发 → 函数 → 连接的简化理解模型DDD 工程脚手架轻量版HTTP Guava Quartz与标准版Dubbo Redis ShardingJdbc XXL-JOB RocketMQ两套脚手架通过mvn clean install安装、IDEA Maven Archetype 创建工程、docker-compose up -d一键安装分布式环境Nacos 8848、RocketMQ 8080、XXL-JOB 9090、Redis 8081、MySQL 8899大营销项目 DDD 落地指引战略建模→ 战术架构→ 战役编码三阶段的完整研发设计评审案例演示如何从产品 PRD、用例图、事件风暴一路落到工程编码。从仓库中多个实战项目的落地情况可以推断如 大营销项目、s-pay-mall DDD 工程模型这套api / app / domain / infrastructure / trigger / types / case的多模块工程模型已成为仓库中各 DDD 实战项目统一遵循的骨架标准。理解了本文的工程模型再配合四色建模战略与设计模式战役即可将 DDD 从听过理论推进到写出可维护、可迭代的工程。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐AppAuth-Android安全最佳实践保护用户数据的7个关键策略AppAuth Android安全最佳实践保护用户数据的7个关键策略 AppAuth Android是一个遵循OAuth 2.0和OpenID Connect应用安全移动开发小型支付商城 DDD 工程模型从 MVC 堆砌到领域分层落地指南小型支付商城 DDD 工程模型从 MVC 堆砌到领域分层落地指南 本文是《小型支付商城系统》系列「第1 3节 DDD 工程模型」的完整技术解读聚焦于工程结文档教程后端CodeGuide 实战专栏仿桌面微信 IM 系统的服务端架构设计——从架构目标到 DDD 四层模型落地CodeGuide 实战专栏仿桌面微信 IM 系统的服务端架构设计——从架构目标到 DDD 四层模型落地 本篇基于 《NettyJavaFx 实战仿桌面版文档教程后端上一篇如何优雅地搭建私有化微信公众号RSS订阅系统下一篇log-update 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
