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

[dengkj]

[reaganlee1947]

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

[fengpan567]

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

[Chad0000]

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

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

[reaganlee1947]

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

[stiangao]

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

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

[liylcn]

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

[dengkj]

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

[hoopan]

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

[yule111222]

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

[ymmud]

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

[reaganlee1947]

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

[yule111222]

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

[TWorldIsNButThis]

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

[TWorldIsNButThis]

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

[yule111222]

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

[klo424]

学习了，感谢 OP 开贴。

[sadfQED2]

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

[yule111222]

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

[dengkj]

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

[twing37]

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