各位所在公司有 DDD 的落地实现吗？

感觉这玩意还在炒作期，等到冷静期再说。

DDD 落地还是挺多的，几年前就比较热了。
曾经实操过一个，感觉不错，但是前期比较花时间

思想很重要，落地是另外一回事，符合自身的一套实践才是最有价值的。

思想觉得是不错，但是感觉站在公司的角度一般不会这么搞。。。毕竟现在还没有成熟

@Rwing 个人项目吗

做过的几个项目都是 DDD ，基本上大组里的项目也都是 DDD 思想了，但是领域到底多合理，也说不上来，感觉领域层设计也没有特别缜密的设计。用起来倒是感觉也还不错

值得学习和参考
落地挺难的，需要所有人（包括客户）的水平都到位，而且资源充足

自己玩玩还行，在公司推就算了

@chendy 是的，感觉在公司落地挺难的，小公司新项目还好点

@3country 公司项目，ddd 其实成熟好多年了，.NET 领域挺多的，主要是公司愿不愿意在前期付出较多的成本，再者项目够不够大

ddd 在于思路不在于怎么编码.

同意 需要所有人的水平都到位 不然挺难落地

文章呢？

@ericgui 放在附言里了

DDD 要一个能说上话的，思路清晰的好架构师，前期花时间分析规划，不然硬套只能徒增复杂度

DDD 里面确实有一系列指导程序编码的战术设计，但更多的是强调概念统一，减少翻译的层数，使得讨论的问题跟编码设计都能够一一对应上。

举个例子，就像一个游戏，五六个人站成一列，最后的那个人在前面那个人的背上写字，然后依次传递信息到第一个人上。人数越多，那么错误的概率也就越大。如果确实有人连字都不认识的话，那么即便只有两三个人也会导致这个问题。

DDD 就是告诉你，在一个建模的框架范围内，大家都具备这些框架的基础理论知识，然后基于这些建模框架构建出一套人人都能理解的模型，使其高度契合产品的业务需求，避免产生概念 /模型不一致的情况。

楼上说还在炒作期的是不是有点落后了，我 14 年写代码时就在用 DDD 了，还是个小公司

难，没有领域专家。开发连业务流程都是懵的。
直接对着原型糊三层架构完事。

git 上有没有 ddd 练手的项目推荐下

如果业务以中文沟通，那么变量函数 URL 用中文命名就实现了一半的 DDD

使用 ddd 指导业务开发，而不能照搬 ddd 模式去写代码

ddd 在我的理解里面就是在拆分和分析业务时非常有用，具体的代码实现，按照组内规范去做就好了。

这东西跟 restful 一样，本身属于是一种架构设计风格。
他们最大的缺陷就是在于想象很美好，现实很骨感。
一旦落地到实际应用里，真按照规范来操作反而会异常的别扭。
所以我的建议是对这些规范适当借鉴吸取，而非全盘照搬。

我很讨厌那些没敲几年代码水平一般，但是整天把 restful 规范挂嘴上的人，一天到晚没事干跑到版面争论业务 code 和 http status code 要不要分开的问题。《狗头》

别的不说。这篇文档阅读性太差。

这文档光引言就说了 DDD13 次。通篇提及“DDD”21 次，也没解释什么是 DDD 。甚至连 DDD 的全称是什么都没写过。

让人心理极度不适。

ddd 不是老生常谈了吗，实际上用的还是 dao 、service 那套

思想早就普遍应用了吧。完整规范太重了，全部照搬不合适，中小系统适当参考还不错。

落地了 Deadline-Driven Development 挺好的

真落地的话，对开发团队和架构师的要求都很高，这点成本无脑搞 java 微服务产出更高不香么？

老瓶装新酒，DDD 往大了说山头主义，往小了说 OOP 里的封装而已。TDD 才是各位应该实践的真知。

用过 PDD

好多 DDD 教徒，我工作中接触过几个，发现都是形式大于内容的货色...

python 看了沉默，golang 听了摇头，php 直呼牛逼。

解决什么问题
你有没有遇到同样问题？

别说落地。。。现在都只是在网上听说过。感觉根本就不是门槛问题，主要这东西学院味太浓，工业界不实用。

论如何写出优雅的业务代码

加个层改个名字，DDD Done /狗头

云山新项目都走 ddd 了

https://i.loli.net/2021/11/17/SrL1gq3ncYMXd5W.jpg
业务好更重要

新项目用 DDD ， 老项目在往 DDD 重构中， 项目前期比较花时间，部分项目已落地，不能照搬 ddd 模式吧，按实际具体业务

@flighter #39 对的没必要照搬，就像 restful 。这个只要做到了业务拆清楚就已经帮助很多了。

国内大部分项目都是一锤子买卖，用 DDD 怕不是自己玩死自己，在国内做项目快速开发比较重要，然后钱收到了，谁爱维护谁维护去！

没有，这玩意思想是好的，但没法照本宣科去落地。当然，就领域的划分而言，用在微服务上面是极好的。

.NET 看了一脸懵逼，这不是教科书式的常规操作吗，有啥特别的...

上家公司有个项目组用 DDD ，开发了 3 年才成型（期间迭代了 3 个大版本，3 年是那个项目 leader 自己说的），好不容易熬出头了，疫情来了，公司（旅游相关）快倒闭了

如果你一个项目的寿命比超过 3 年，你搞什么 DDD

中国民营企业平均寿命 3.7 年，中小企业平均寿命 2.5 年

你们感受一下

说实话没太懂 DDD

我司有个项目组用的阿里巴巴的 DDD 框架 COLA 落地了项目了，整的还挺好的。

DDD 和六边形架构要区分清楚啊，文章中这个上来就是代码一定不是 DDD 。
DDD 要梳理业务，划分上下文、聚合（一般是事件风暴法），最后得到一个业务模型，到这一步为止一行代码都没有。之后是用代码实现这个模型，六边形是常见但不是唯一的实现架构。
DDD 的核心就是这个建模过程，没有建模就上代码属于无源之水

oop 搞明白就行了

@Jooooooooo 好家伙，你搞明白了。领域编程，其实就是在乎思想。由于我们写方法 /函数 基本一定是 过程化编程，那么就会习惯性导致整个系统项目都是过程化编程，所以要整个项目都是面向对象编程其实很难。

@xhinliang 不仅仅是形式，太菜了，mad 。公司也有一些这样的人，也是有。


我一般推荐 ddd 在微服务上践行，单个服务就是一个领域，不管你用啥编程模型和语言。但是整个微服务作为一个系统，应该要符合 DDD 的思想，就是一个 DDD 设计出来的系统，符合 DDD 的基本规则规范。

DDD 落地很难，不理解 DDD 思想的人去看 DDD 架构的代码会觉得很多无法理解的奇怪行为，实际操作起来也确实比较麻烦和费事，好处是更新维护心理负担少了。

@fuxkcsdn https://www.mysmth.net/nForum/#!article/WorkLife/2731643 是这个公司吗？

DDD 开发差不多两年，目录结构照 ddd 模式套，实际上还是面相过程，仅仅做到的就是把 domian 贫血模型，改成充血，service 业务放入 domain 处理。

@SmiteChow 别说 TDD ，光是使用面向对象把业务模型和逻辑理清楚很多都做不到。

@docker2018 cola 一年更新 4 个大版本,ali 有项目用这玩意儿我就倒立洗头

核心是要紧密贴合业务, 统一语言, 做专家系统

@qwe520liao 不是

@BQsummer 这就不要杠了，人家问的是有落地与否，我只是说一下我司是落地了的。

目前我司正处于使用 DDD 完全重构所有服务的尾声。附一篇个人觉得好的文章
https://mp.weixin.qq.com/s/PjNc7YLKT5JX_Obg2815Bg