下述内容如果有什么不正确的地方 欢迎各位大佬指正 本人也正在学习中

这里推荐一篇文章：https://tech.meituan.com/2017/12/22/ddd-in-practice.html

前段时间看到了DDD，听佬友们说这是一个大型项目的项目结构设计方法论，但是说起来可能我的见识面太短了，我仅看到过MVC、MVVM的项目，DDD还真没怎么见人用过，于是乎，我去研究了一波，感觉还是蛮复杂的，我也没捋清楚真正的DDD是什么样的

接下来针对性的说明一下我对DDD的理解 DDD是一种领域驱动设计，其实就是一种方法论，用于划分领域 DDD是页面->接口层->应用层->领域层->通用层，这样递进的关系

• 接口层其实就相当于接收请求及参数
• 应用层是处理业务编排的，业务编排简单来说就是给很多服务发布任务
• 领域层是处理具体业务的，里面包含了业务层、实体层、数据接口层
• 通用层是辅助工具，所有的应用层及领域层的工具、配置类都从这里拿，可以说是一个tools

我研究了一些DDD单体项目的源码，通常是页面传输信息给接口层，即interface interface调用应用层，即application

在application中针对所有的领域层功能做业务编排，即针对domain做业务编排 这里需要详细重点的来说明业务编排 业务编排其实并不是来写业务逻辑代码，而是来调用domain中的service、repository等功能，针对性的获取业务所需的信息，给予对应的业务功能，通过service或repository去做一些业务操作，简单来说就是：调service、repository的方法来用，最终给interface返回想要的东西 这样的好处其实就是让业务层只需要针对性去做业务代码，无需其他调用功能，解耦合

此时在domain中，存在着service、repository，它俩就可以调用通用层tools，即调用infrastructure

至此，完美解耦合了

其实我之前一直在使用MVC，在小型项目上蛮好用的，但由于自己也只是一个个人开发者，接触大型项目的机会很少，所以几乎碰不到DDD，MVC在小型项目上来说，我承认，快速开发，好理解，controller、service、mapper，太好用了，太方便了 但是当项目架构过大时，管理不易，业务全堆积在了service下

什么项目才算大呢？

我觉得可能几十个模块才算大吧，没有必要折磨自己用DDD，哈哈哈哈哈