02 《没有废话！说明白点！》——1分钟了解DDD

1 前言

最近在牛客看到一篇关于DDD的文章，完全看不懂，决定自己白话文一下，让各位老哥知道其大概思想。本篇全都是用自己的词语来表述这个DDD。

2 我的理解

DDD是一个代码架构设计方法。

使用Java写Spring的时候，我们会使用XxxController来映射接口，XxxService来执行逻辑业务，XxxMapper来进行持久化，这样的写法叫做MVC。

我不知道老哥们是怎么写的，我说一下我自己追求的MVC架构：

• Controller层只捕获异常，将调用的对象转化，传递给Service，让Service层执行。
• Service层负责主要业务逻辑，分为三层：
  • 上一层靠近业务，例如LoginService、RegisterService。
  • 下一层靠近Mapper，但是针对的是联结的情况，例如StudentTeacherService，主要是因为这些方法放到StudentMapper和TeacherMapper都不合适，索性抽出来了，同时还可以加上事务，就不用直接写SQL来搞这种事情。
  • 中间一层，就既不是上层，也不是下层的，例如RedisService。
• Mapper层负责和数据库打交道，为Service层提供持久化，例如UserMapper，或者UserDAO。

DDD和MVC差不多，但是有点不太一样了：

主要分了下面几层：

• 接口层：和上面提到的Controller的一模一样，只是名字改成了XxxApi，然后数据转化那里抽象出一个Assembler，实现DTO到DO的转化，这个好理解。
• 应用层：这里和之前的Service层有点不一样，我之前不是说过，我把Service层分为三个层么，这里只有我提到的上一层，即只负责业务层，例如LoginService、RegisterService、或者提供给用户增删改查的PersonService这种。方便接口层直接调用，然后使用try-catch捕获异常，使用Assembler转化返回结果。
• 领域层：这一层完全不一样，它提供了领域的概念。领域这玩意像某个抽象中心一样，领域的实体都围绕着这种中心，例如Person和Order就是两个领域，然后针对这个中心提供下面的几个：
  • 针对这个领域提供对应的实体，例如Order领域，里面有OrderOwner、OrderItems、Payment什么的，全部都围绕Order展开，又例如User领域，有User、Role、Authorization等等。尽管不同领域之间有重合的部分。
  • 针对这个领域提供应用层可用的接口，命名为XxxDomainService，然后应用层就用这个和领域层沟通。
  • 针对这个领域提供持久化的接口，之后在基础层可以实现接口，这就和持久化隔离开来。
• 基础设施层：就提供一些通用的服务，例如整体的配置、工具类、通用的算法、持久层等等，就是放一些杂项。

3 总结

本质上，DDD只是强调了“Service领域化”这个思路，围绕着这个思路，把MVC混乱的Service层，拆分然后归属到不同领域，大大降低耦合性和服务复杂性。以至于之后要扩展什么业务，仅仅需要添加一个新领域即可完成，这种思维方式高效，实在是佩服。

最后，假如这篇文章对你有帮助，记得点赞收藏送花，假如有错欢迎批评指正。同时也欢迎各位在评论区提出自己的想法。