Update ddd-guide-00.md

docs/md/road-map/ddd-guide-00.md

@@ -56,8 +56,8 @@ lock: need
 </div>
 
 - 首先，一个分布式架构要，对接 rpc、提供 rpc、消费 mq、生产 mq，还要做定时任务（最终一致性补偿），单一个 rpc 的使用，就需要在程序定义出一个 export 层，要打包对外的服务接口，让使用方式引入使用。关于为什么需要这样的方式，可以在 [bugstack.cn](https://bugstack.cn/md/road-map/dubbo.html) 编程路书中，开发技术部分 dubbo 学习。
-- 之后，原本的 MVC 三层结构就不够用了。只要添加上，export、rpc 这样的分层，原本 service 直接处理数据库的操作，也要考虑拆分出来。可能这部分每个公司还不一样，其实即使一个公司，不同组，也是有很大的差异。这个也是目前互联网公司中的项目里的一个现状问题。
-- 思考，现在的工程模型结构其实很杂，装填了太多的东西进去了。除此之外，因为都是原子化编写，没有在做分区。一个系统里 service 都有上千个类，每个类里又有上千行代码。在坐的各位，应该都会在这些屎山中赚钱。
+- 之后，原本的 MVC 三层结构就不够用了。只要添加上 export、rpc 这样的分层，原本 service 直接处理数据库的操作，也要考虑拆分出来。可能这部分每个公司还不一样，其实即使一个公司，不同组，也是有很大的差异。这个也是目前互联网公司中的项目里的一个现状问题。
+- 思考，现在的工程模型结构其实很杂，装填了太多的东西进去了。除此之外，因为都是原子化编写，没有在做分区。一个系统里 service 都有上千个类，每个类里又有上千行代码。在座的各位，应该都会在这些屎山中赚钱。
 
 ## 四、四层架构
 
@@ -69,8 +69,8 @@ DDD 是思想，六边形/菱形/整洁架构是分层，DDD 通过建模思想
     <img src="https://bugstack.cn/images/roadmap/tutorial/road-map-architectural-design-04.png" width="600px">
 </div>
 
-- 首先，六边形架构，以 DDD 领域驱动实际为指引，为 domai 层，设计充血模型结构，如；登录、下单、支付，在每个模块下，包含完整的服务、模型、适配。适配的目的是这个领域里所需的数据，都通过适配的方式从外部调用进来，比如；数据库、缓存、接口等。这是一种 ACL 防腐设计，将来外部的接口变化了，也不会影响我们的领域服务，只要按照领域服务的适配标准提供即可。
-- 之后，围绕着领域 domain 开始，需要啥就让外部的基础设施层实现领域层的接口来提供。而接口要提供啥能力，就调用 case 编排 domain 层，或则简单的由 domain 层直接提供也可以。
+- 首先，六边形架构，以 DDD 领域驱动实际为指引，为 domain 层，设计充血模型结构，如：登录、下单、支付。在每个模块下，包含完整的服务、模型、适配。适配的目的是这个领域里所需的数据，都通过适配的方式从外部调用进来，比如：数据库、缓存、接口等。这是一种 ACL 防腐设计，将来外部的接口变化了，也不会影响我们的领域服务，只要按照领域服务的适配标准提供即可。
+- 之后，围绕着领域 domain 开始，需要啥就让外部的基础设施层实现领域层的接口来提供。而接口要提供啥能力，就调用 case 编排 domain 层，或者简单的由 domain 层直接提供也可以。
 - 最后，也就是 trigger 触发器，我们把接口、任务、mq等都理解为一种触发，之后让 trigger 调用 case 层。case 或者 domain 的目的，就是分摊 trigger 以前 Controller 编写逻辑代码的压力。让 trigger 只是负责对外逻辑的封装，错误码，异常即可。
 
 综上，就是关于架构分层的一个演进过程，现在还有 AI 的加入，AI 也会逐步成为整个工程架构中的一块。关于这部分的架构设计，与业务工程的结合，小傅哥也会在 bugstack.cn 博客中陆续更新。