概述
最近有一个项目要使用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; //实现业务1Service2 service2; //实现业务2result 方法一(){//1.加载数据or参数校验————————————//2.业务检查---dumplingname();判断//3.实现具体业务(当具体业务发生变化的时候，可以直接更改具体实现的service)result ss1 = service1.getname();.//得到最后的数据，做返回或处理.}
}
注：xxxrepository用以实现数据存储总结
1.也不是每个项目都适合使用DDD模式的，最好是当项目后期迭代会比较频繁，项目比较大，这样的话使用DDD的模式来做，后期维护会方便。
2.DDD其实看个人的理解，因为这个领域的划分，基本上是按照你对这个模块的理解来划分的，可能换一个人来，又会有不同的理解。
3.总之DDD是一种尝试，是对微服务的一种补充，但不是绝对必要，根据需要选择。
