一.前言 hello，everyone。 昨天在掘金看到了这么一篇文章：拥抱毒瘤 DDD！ 鄙人不才，近期在做DDD落地，并且也发了几篇系列文章，在github上也上传了demo 看到他写的喷文，我直

最近我发现团队项目中的某个应用复杂度越来越高，具体表现为： - 代码可读性较差：各个服务之间调用复杂，流程不清晰 - 修改部分业务导致大量测试用例失败，但很难快速的寻找出这些测试用例失败的根因

在一个DDD架构设计中，领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务，特别是在一个业务逻辑相对复杂应用中，每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的…

在过去一年我们团队做了大量老系统重构和迁移，其中有大量代码属于流水账代码，通常能看到是开发在对外的API接口里直接写业务逻辑代码，或者在一个服务里大量的堆接口，导致业务逻辑实际无法收敛。

3.1. 实现动态路由的数据加载 3.2. 创建配置类 3.3. 添加Nacos路由配置

接上一篇 直播录制鉴黄配置 人脸核身 直播推拉流 直播录制鉴黄配置 接完直播录制鉴黄等配置后，需要由腾讯云回调至服务端，服务端收到回调后做相对应的处理 创建成功后，还需到对应的推流域名下关联 回调配置

之前整理过《DDD分层》 以及《分层架构》 最近看网友讨论，整理一些有亮点的地方 现在分层架构+整洁架构似乎是个万金油组合了 之前DDD的标准分层结构： 右边传统分层，左边经过DIP改进型，两者有什么

Nest.js 是一个现代的企业级 Node.js web 框架，在最近使用 Nest.js 实践一些项目的总结了一些使用心得，但也从中学到了很多东西，在这里总结下来和大家分享。