eastwind
(WindyDante)
1
下述内容如果有什么不正确的地方 欢迎各位大佬指正 本人也正在学习中
前段时间看到了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，哈哈哈哈哈
5 Likes
github冲浪的时候刷到过一个DDD架构的框架，有的能看明白，有的完全看不懂…
2 Likes
哈哈哈哈，我已经收藏吃灰很久了，我能力肯定用不起来 
1 Like
让我想到了十几年前一个哥们就开始布道ddd，这么多年才火起来，我还记得那个叫什么解道框架
2 Likes
没有印象，ddd确实提出了很久很久了，但是对人技术门槛要求有点高，尤其是越大的开发团队越不友好
Joyle
(Joyle)
9
DDD 并不是什么架构，而是软件设计的价值取向。“领域驱动设计”这个词的意思是把“识别各种范围和边界”作为软件设计的核心驱动力。而为什么要识别边界？因为系统的复杂度可以说是由系统元素的数量及元素之间的关系构成的，且元素之间的关系对系统复杂度的影响远大于元素数量所产生的影响。所以“识别边界，划分领域”就是用数量来简化关系，将大问题拆解为小问题，将复杂度控制在有限范围内，从而降低系统整体复杂度，提升系统可维护性
2 Likes
xray
(xray)
15
DDD是一种面向业务的软件构建方法论，目的是让技术实现和业务架构保持一至，关键在于理解业务，战略是搞清楚业务的核心竞争力（识别核心域，分拆业务边界控制变化，保证核心域的稳定性），哪里要多投入（通过聚焦核心域平稳资源）；战术可以看成是一种设计模式（代码如何与业务概念结合，拉近业务理解[比如不是写成handler/process，而是写成业务语义如deposit/withdraw..]，做到看代码就看懂业务，以有效控制变化）
如果domain service usecase划分的不好，会比mvc更乱
Skiyee
(sKy)
17
这玩意要是拆不明白就完全是折磨自己，顺便把别人也给折磨了
libook
(libook)
18
个人理解DDD和MVC不是一个维度上的概念。MVC是单个服务的一种架构设计模式，对于一个现实的业务来说可以采用宏服的务设计也可以采用微服务（即将业务拆解为多个可复用的微服务）的设计，而DDD更多是在微服务设计基础上来合理划分微服务的方法。
一种领域划分方法论吧，我觉得大型项目重构是可以的。新项目一上来就DDD不适合，因为领域会持续迭代变化，不稳定
