有实践过领域驱动设计（DDD）的吗？
source link: https://www.v2ex.com/t/945258
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
 |
reaganlee1947 3 小时 51 分钟前 公司某绩效系统使用的阿里的 COLA-DDD 框架，但是使用下来感觉 DDD 目前还是不太成熟。可能是我才疏学浅 😭
|
 |
fengpan567 3 小时 49 分钟前 很难搞，必须有个 DDD 专家指导才行，不然每个组都是不同风格的 DDD
|
 |
Chad0000 3 小时 48 分钟前 via iPhone 这个就跟 restful 一样，个人认为不需要照搬。
我现在设计系统的原则是每个模块完全独立，不要依赖其他模块，然后由流程模块协调所有模块。 |
|
reaganlee1947 3 小时 48 分钟前 @fengpan567 最后开发下来有些同事还是写成了 MVC 谁懂啊
|
 |
stiangao 3 小时 41 分钟前 17 年开始接触，到现在实践下来的经验就是，DDD 是一种思想，不是模式，所以直接用别人的框架还不如自己搞，
确实需要有经验的人来做边界划分 |
 |
liylcn 3 小时 38 分钟前 @fengpan567 是的
而且有个问题，DDD 适用于大规模协作项目，一般公司都没这条件，几个人玩项目很繁琐。。 |
 |
dengkj 3 小时 31 分钟前 看来都觉得 DDD 实践起来比较难，那你们项目一般怎样分层？
|
 |
hoopan 3 小时 10 分钟前 刚看的微服务架构设计里，也提到用 DDD 拆分服务，没太看懂。
|
 |
yule111222 3 小时 2 分钟前 我已经大规模实践过了，非常香，再回去做非 DDD 的工程很难受
推荐《解构领域驱动设计》 |
 |
ymmud 2 小时 59 分钟前 团队整体水平不行的尽早放弃摆烂
|
|
reaganlee1947 2 小时 59 分钟前 @yule111222 但感觉要把业务逻辑和 CRUD 数据库操作完全脱钩，在现在使用 Mybatis 这些框架的的情况下有点困难。
|
|
yule111222 2 小时 55 分钟前 @reaganlee1947 ORM 框架是个伪 命题，根本不存在。其次，这个只是一个技术基础设施，不论你用什么框架都不会影响领域层的代码。核心业务需要跟技术基础设施完全分离解耦合 再推荐《架构整洁之道》
DDD 属于上层应用方法论里面对综合要求比较多的，需要深入理解设计原则，整洁架构，面向对象，抽象建模等多种能力，才能较好的落地实现。如果没有这方面的专家还是不要轻易尝试的好，容易适得其反 |
 |
TWorldIsNButThis 2 小时 54 分钟前 via iPhone 有
不过我是先做了一年有点感觉，最近才补理论，以前没做的时候感觉云里雾里的概念现在感觉都很自然，好像本来就应该这样 |
|
TWorldIsNButThis 2 小时 49 分钟前 via iPhone |
|
yule111222 2 小时 48 分钟前 @reaganlee1947 任何业务逻辑如果需要优雅的实现更好的复用，都需要更复杂的数据结构来支撑。这本身就跟数据库是脱钩的。为什么 Redis 可以实现那么多数据结构，因为是内存数据库。持久化操作仅仅是内存快照(RDB)和指令日志(AOF)的结合。试想一下，如果你的系统运行在一个内存无限大且不需要持久化到数据库里面的环境中，你会如何进行设计？无论用不用 DDD 推荐的工程架构，纯粹的 OOP 方法本身也不需要考虑持久化。在 DDD 的方法里面这部分工作外包给了 Repository 来完成，这个东西本质上是一个适配器，相当于持久化基础设施与核心之间的桥梁。也可以类比 Linux 的 VFS 系统，为什么 Linux 可以支持那么多文件系统而内核维持在很小的体量，也是类似的方法
|
 |
klo424 2 小时 43 分钟前 学习了，感谢 OP 开贴。
|
 |
sadfQED2 2 小时 40 分钟前 via Android 实践过，每个人对 DDD 的理解都不一样。团队整体水平不行的话，尽早摆烂放弃。
|
|
yule111222 2 小时 30 分钟前 为什么面向关系数据库的建模方法不够好呢？
有如下原因： 1.二维表难以表达层次结构，出于性能考虑不太可能把一个实体拆分成多张表，这就容易导致复杂的实体表字段非常多认知负担高，且模型难以复用。领域模型通过实体和值对象解决了这个问题 2.二维表也无法表达继承关系，比如 3 个子类继承于同一个父类，它们可以存储在同一个数据库表里面。从表模型上就看不出继承关系了。领域模型是基于 OOP 的，天然可以表达继承关系 3.二维表无法对行为和事件建模，难以表达动态性，领域模型里面可以对领域服务和领域事件建模 4.二维表难以表达关系耦合松紧程度，领域模型通过聚合来约束这个 |
|
dengkj 2 小时 30 分钟前 @TWorldIsNButThis 语言特性太弱导致要写大量适配代码可以举个例子吗？
|
 |
twing37 2 小时 28 分钟前 ddd 教给我们一个是从地球看月球,再从月球看地球的多角度看问题的方式.从而让自己的核心代码稳定而非四处修改,这不是准则,也不是银弹.
|
|
dengkj 2 小时 28 分钟前 @yule111222 方便说一下实践时的团队规模及架构吗
|
|
yule111222 2 小时 27 分钟前 @yule111222 补充一下，实体和值对象本身也有行为，也能表达动态性
|
|
yule111222 2 小时 25 分钟前 @dengkj 技术团队 40 人左右，不过其实和规模无关，和人的能力有关。能力到位了，1 个人也可以用。
规模更多的是决定了工程架构和服务划分的方式，规模小可以把多个 子领域 放到一个工程里面，通过多模块来切分。 |
|
dengkj 2 小时 23 分钟前 @yule111222 实践过程中用什么工具（例如 UML 类图）来表达限界上下文以及领域模型？
|
|
yule111222 2 小时 23 分钟前 @dengkj processon
|
 |
rozbo 2 小时 20 分钟前 我用 DDD 两年了，总结一下，小项目小团队只要有这个思想就好了，没必要完全做到。。但是如果真的做到了，除了效率低一点，后续的维护真的很香
|
|
dengkj 2 小时 18 分钟前 @yule111222 团队规模大小只会影响服务划分，工程架构应该都是一致的吧？比如按照用户接口层、应用层、领域层、基础设施层这样。
|
|
dengkj 2 小时 16 分钟前 @yule111222 ProcessOn 是个好工具，其实我是想问限界上下文通过什么图来描述？
|
|
yule111222 2 小时 13 分钟前 @dengkj 我没找到特别好的工具，但是这个东西比较抽象和简单 processon 也能画的，弄几个椭圆画几根线就行。 工程架构也会影响，多子域放到一个工程里 和 每个子领域一个服务的架构上是有区别的，不过对分层影响是不大。我本人使用的是自创的架构，基于菱形对称架构改造而来的
|
|
dengkj 1 小时 49 分钟前 @reaganlee1947 谢谢，我参考一下
|
|
dengkj 1 小时 49 分钟前 @yule111222 好的，谢谢解答，我自己去实践一下
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK