这篇博客展示了DDD设计前后的代码结构对比，重点讨论了事务脚本式（贫血模型）代码和DDD改造后的充血模型代码。作者通过分析旧代码的Controller、Entity、Mapper和服务层，指出其代码结构和业务之间的异构性。接着，介绍了采用DDD设计的新代码结构，包括边缘层、基础层、限界上下文、业务价值层、菱形架构的领域层、北向网关、南向网关和发布语言层，强调领域层作为业务逻辑核心的重要性。
Talking is easy, show me your code
真正开始 DDD 旅程前，我想让您看到经过 DDD 设计之后的代码长啥样。我想，这是所有本着“talking is easy, show me your code”理念的程序员都比较在乎的观念。
为此，我特别将“群买菜”生鲜电商系统服务端代码新旧代码结构都显示出来，让您看看原来的旧代码——也就是“事务脚本式”代码长啥样（应该是目前大部分 java 程序员写代码的样子），再让您看看 DDD 改造设计后的新代码长什么样子。然后再通过分析，说清楚为什么传统的“事务脚本”代码不是对真实世界的“同构映射”，而 DDD 代码的“同构映射”在哪。
需要提醒您的是：从今天这个专题开始，可能需要你多花点时间、深入地阅读我写的代码、和文字的每一句话，反复对照着看，甚至来回反复多看几遍，才能真的去理解这些文字了。
旧代码：事务脚本式（贫血模型）代码
我们先来看旧代码的目录结构截图。注意看下面的 1、2、3、4 标注位置（解释下，我这里用的是 spring-boot 开发框架，MyBatisPlus 数据持久框架、MySql5.6 数据库）：
您注意到这里标注的 1、2、3、4 代码位置了吗？是不是代码结构很像大部分 spring-boot 应用框架下代码结构？为了避免您可能不太了解这种代码结构，我还是简单解释下：
-
标号 1 位置：这里放的是 Controller（控制器）层代码，也就是所有前端访问的接口都在这里实现。按照 MVC 的分层原则，一般来说，这里只会放一些客户端输入参数的解析、以及对 service 层（见下文）的业务方法调用。一般来说，这里的代码都长成下面这样：
-
标号 2 位置：这里放的是 entity（数据 bean）层代码，其实都是 POJO 代码，所有类都一一对应到数据库表。一般来说，这里的代码都长成这样：
-
标号 3 位置：mapper 层，对于 mybatis 持久层框架来说，mapper 和 entity 共同实现了 ORM（对象模型到关系模型的映射）。一般来说，这里的代码长成这样（这里 CustomerMapper 类只是定义了 entity 类 Customer 的映射关系，以及自定义的数据操作方法）：
最低0.47元/天 解锁文章
扫一扫
1801
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
