有实践过领域驱动设计（DDD）的吗？

公司某绩效系统使用的阿里的 COLA-DDD 框架，但是使用下来感觉 DDD 目前还是不太成熟。可能是我才疏学浅

很难搞，必须有个 DDD 专家指导才行，不然每个组都是不同风格的 DDD

这个就跟 restful 一样，个人认为不需要照搬。

我现在设计系统的原则是每个模块完全独立，不要依赖其他模块，然后由流程模块协调所有模块。

@fengpan567 最后开发下来有些同事还是写成了 MVC 谁懂啊

17 年开始接触，到现在实践下来的经验就是，DDD 是一种思想，不是模式，所以直接用别人的框架还不如自己搞，

确实需要有经验的人来做边界划分

@fengpan567 是的
而且有个问题，DDD 适用于大规模协作项目，一般公司都没这条件，几个人玩项目很繁琐。。

看来都觉得 DDD 实践起来比较难，那你们项目一般怎样分层？

刚看的微服务架构设计里，也提到用 DDD 拆分服务，没太看懂。

我已经大规模实践过了，非常香，再回去做非 DDD 的工程很难受
推荐《解构领域驱动设计》

团队整体水平不行的尽早放弃摆烂

@yule111222 但感觉要把业务逻辑和 CRUD 数据库操作完全脱钩，在现在使用 Mybatis 这些框架的的情况下有点困难。

@reaganlee1947 ORM 框架是个伪 命题，根本不存在。其次，这个只是一个技术基础设施，不论你用什么框架都不会影响领域层的代码。核心业务需要跟技术基础设施完全分离解耦合 再推荐《架构整洁之道》
DDD 属于上层应用方法论里面对综合要求比较多的，需要深入理解设计原则，整洁架构，面向对象，抽象建模等多种能力，才能较好的落地实现。如果没有这方面的专家还是不要轻易尝试的好，容易适得其反

有
不过我是先做了一年有点感觉，最近才补理论，以前没做的时候感觉云里雾里的概念现在感觉都很自然，好像本来就应该这样

@reaganlee1947 是这样的
DDD 是彻底的 IoC ，不是由技术表达业务，而是一切由业务驱动，让技术去实现业务
Java 语言特性太弱，如果要实现这个目标要写大量的适配代码

@reaganlee1947 任何业务逻辑如果需要优雅的实现更好的复用，都需要更复杂的数据结构来支撑。这本身就跟数据库是脱钩的。为什么 Redis 可以实现那么多数据结构，因为是内存数据库。持久化操作仅仅是内存快照(RDB)和指令日志(AOF)的结合。试想一下，如果你的系统运行在一个内存无限大且不需要持久化到数据库里面的环境中，你会如何进行设计？无论用不用 DDD 推荐的工程架构，纯粹的 OOP 方法本身也不需要考虑持久化。在 DDD 的方法里面这部分工作外包给了 Repository 来完成，这个东西本质上是一个适配器，相当于持久化基础设施与核心之间的桥梁。也可以类比 Linux 的 VFS 系统，为什么 Linux 可以支持那么多文件系统而内核维持在很小的体量，也是类似的方法

学习了，感谢 OP 开贴。

实践过，每个人对 DDD 的理解都不一样。团队整体水平不行的话，尽早摆烂放弃。

为什么面向关系数据库的建模方法不够好呢？
有如下原因：
1.二维表难以表达层次结构，出于性能考虑不太可能把一个实体拆分成多张表，这就容易导致复杂的实体表字段非常多认知负担高，且模型难以复用。领域模型通过实体和值对象解决了这个问题
2.二维表也无法表达继承关系，比如 3 个子类继承于同一个父类，它们可以存储在同一个数据库表里面。从表模型上就看不出继承关系了。领域模型是基于 OOP 的，天然可以表达继承关系
3.二维表无法对行为和事件建模，难以表达动态性，领域模型里面可以对领域服务和领域事件建模
4.二维表难以表达关系耦合松紧程度，领域模型通过聚合来约束这个

@TWorldIsNButThis 语言特性太弱导致要写大量适配代码可以举个例子吗？

ddd 教给我们一个是从地球看月球,再从月球看地球的多角度看问题的方式.从而让自己的核心代码稳定而非四处修改,这不是准则,也不是银弹.

@yule111222 方便说一下实践时的团队规模及架构吗

@yule111222 补充一下，实体和值对象本身也有行为，也能表达动态性

@dengkj 技术团队 40 人左右，不过其实和规模无关，和人的能力有关。能力到位了，1 个人也可以用。
规模更多的是决定了工程架构和服务划分的方式，规模小可以把多个 子领域 放到一个工程里面，通过多模块来切分。

@yule111222 实践过程中用什么工具（例如 UML 类图）来表达限界上下文以及领域模型？

@dengkj processon

我用 DDD 两年了，总结一下，小项目小团队只要有这个思想就好了，没必要完全做到。。但是如果真的做到了，除了效率低一点，后续的维护真的很香

@yule111222 团队规模大小只会影响服务划分，工程架构应该都是一致的吧？比如按照用户接口层、应用层、领域层、基础设施层这样。

@yule111222 ProcessOn 是个好工具，其实我是想问限界上下文通过什么图来描述？

@dengkj 我没找到特别好的工具，但是这个东西比较抽象和简单 processon 也能画的，弄几个椭圆画几根线就行。 工程架构也会影响，多子域放到一个工程里 和 每个子领域一个服务的架构上是有区别的，不过对分层影响是不大。我本人使用的是自创的架构，基于菱形对称架构改造而来的

@dengkj Event storming 能很好的进行领域分析
@SeAlso: https://www.eventstorming.com/

@dengkj 如果非要参考的话

<img src="https://camo.githubusercontent.com/7794e7335aa77e2a271b7989c8eb24cd5c5f3cd8efa77aebd71b858524051573/68747470733a2f2f696d672d626c6f672e6373646e696d672e636e2f36353439323330633637323334343866623361623531636137343832396538302e706e67" alt="cola arch" data-canonical-src="https://img-blog.csdnimg.cn/6549230c6723448fb3ab51ca74829e80.png" style="max-width: 100%;">

https://github.com/alibaba/COLA

@reaganlee1947 谢谢，我参考一下

@yule111222 好的，谢谢解答，我自己去实践一下

@TWorldIsNButThis Java 是面向对象的语言还弱

@TWorldIsNButThis 这，认真的吗，Java ood 语言还弱

我毕业刚入职的时候部门就已经在用 ddd 了，我之前没有任何企业开发经验，导致我一直不太明白 ddd 具体是啥，只是觉得部门那些服务这样设计是理所当然的。。。后来觉得 ddd 本来也没有什么固定或者最优的模式，每个团队的理解都不一样，我们是有一整个架构组和各个小组的资深同事在维护这个架构，谈不上最优不过收益能比投入的成本大就值得使用了

@iRiddle 羡慕大佬，刚毕业就接触到了 DDD 。就目前的理解来说，DDD 就是一种指导思想，只要把握了分离业务复杂度和技术复杂度这个大方向，具体的架构可以因地制宜。