DDD初步简单理解

概述

最近有一个项目要使用DDD模式来写，大致整理一下笔记。

问题：为什么要使用DDD？大概要怎么使用DDD？

目录

概述

MVC和DDD比较

实例介绍

简洁代码逻辑示例

总结

---

MVC和DDD比较

 MVC（module，view，controller）模式是传统的3层架构的模式。

一般来说一个controller对应一个功能点，controller负责非业务逻辑的代码，service负责业务逻辑的代码，dao负责数据库交互。

DDD（domain，driver，design）模式是，虽然微服务将模块细分，做到了不同模块之间尽量解耦合，使得以往的单机环境负载复杂业务逻辑难，变得轻松。

但是并没有对模块内进一步细分。往往改变一个功能的时候，可能会涉及到其他功能的代码，这样就会导致后期维护没有那么容易。

实例介绍

例如登录系统这个功能。

传统的MVC模式就是：controller负责接收参数，service负责处理业务逻辑，dao和数据库交互。

service层有账号密码验证，手机短信业务的接收等，当功能较少的时候，还好区分，功能一多就很难维护了。

DDD模式：controller负责接收参数，应用层负责组装各个领域，领域层分为各个领域，基础服务层（也就是dao层）。

那么这个登录的功能就可以分为，账号密码验证域，短信业务域等分为很多个域。

 如果域足够大，可以将一个域对应一个实体。

但是通常情况下个人觉得，没必要区分得这么细，实体可以共用。

这样当业务发生变化的时候，是不是就到指定的域中去修改就可以了，不会影响其他业务逻辑，所以DDD主要是便于后期的维护。

简洁代码逻辑示例

xxx controller(){
    Service1 service1; //实现业务1
    Service2 service2; //实现业务2
    
    result 方法一(){
         //1.加载数据or参数校验
         ————————————
         //2.业务检查
         ---dumplingname();判断
         //3.实现具体业务(当具体业务发生变化的时候，可以直接更改具体实现的service)
         result ss1 = service1.getname();.
         //得到最后的数据，做返回或处理.
    }
}
注：xxxrepository用以实现数据存储

总结

1.也不是每个项目都适合使用DDD模式的，最好是当项目后期迭代会比较频繁，项目比较大，这样的话使用DDD的模式来做，后期维护会方便。

2.DDD其实看个人的理解，因为这个领域的划分，基本上是按照你对这个模块的理解来划分的，可能换一个人来，又会有不同的理解。

3.总之DDD是一种尝试，是对微服务的一种补充，但不是绝对必要，根据需要选择。