谁有 ddd（领域驱动设计的相关案例项目）？

不公开的实践项目会很多，但是公开并且规模还足够到可以学习的案例项目，不可能有，别找了。

另一方面，DDD 不只是编程思想，它是涉及需求、交付、开发、测试等全方面的开发思想，如果不能在客户、产品、开发之间形成通用语言的话，那也是用不了的。你可以拿公司的非紧急项目给自己练手用，不要想用 DDD 单方面去解决公司的项目开发困境。

周志明的凤凰架构

DDD 是一套方案, 主要是为深入理解你的业务提供帮助.如果你没有复杂的业务, 或者你的业务天天都在变化, 那 DDD 没啥用.
DDD 在简单的项目上看不出啥用途, 而一旦足够复杂, 现在都是以 DDD 等作为指导思想做微服务切分了. 然后要解决的问题就变成了分布式要解决的问题了.

ddd 是一个过程，而不是你牟足了劲憋出来了最终代码

这个东西比较抽象，属于道层面的东西了，术层面的东西很少，能参考的也有限，而且很多战术和编码实现是有冲突的

@nothingistrue 想了解一下 您说不公开的实践项目很多，是有什么信息来源吗？

@ExiFeng 哪一章是的？之前大致浏览了下，没记得有 ddd 案例啊

@aviator #8 https://github.com/fenixsoft/monolithic_arch_springboot

@ql562482472 应该是大厂有不少组都在做这个，但具体怎么样不好说，我经历过的还行

这东西啊, 就跟元宇宙一个意思, 大家都在吹, 就是看不到

没什么卵用，软件开发的根本问题还是 人月神话指出的那样，

复杂性与概念完整性，

别的系统中很多复杂性不是根本属性，可以剔除掉，只要抓住主要模型就行，例如我们初中学习的物理知识，很多物理题目都是简化后的模型，最常见的就是刚体模型，刚体假设所有系统中的物体都是不会发生形变的，这样的模型系统中就排除了物体形变带来的复杂性

但是软件这东西，复杂性是根本属性，而且复杂性通常又分两种，一种是业务逻辑本身的复杂性，另一种是开发人员人为带来的复杂性，例如复制一段代码，你接手改的时候 莫名其妙漏了一处，这是人为带来的复杂性，

通常应对前者的解决办法就是拆分，拆分的越细就越容易理解，后者基本上只能靠高素质的开发人员，遇到水平低下的，甚至乱搞的，对业内最佳实践不屑一顾的，你只能自求多福，像我最近跟别的部门对接，参数都是 string int ，java interface 一点约束都没有，能用 string 绝对不 enum ，还有提供接口任何时候都不报错，全部直接给你返回 200 ，接口里面几个种参数组合跟各种功能，然后让你去查日志对接，美名其曰 考虑生产性能，我们此处不做校验逻辑，只要开发阶段大家代码调试通过即可。

还有自己又实现了一套本地缓存的，没有任何运维工具跟监控全靠手工维护，线上发布，运维压力直线上升，

DDD 只是可以帮助你去理解概念的完整性，并没有办法让你做的更好，
因为目前国内的情况就是 大量的人都是从事历史悠久的事务脚本开发，模块化都没做好，
何谈用 DDD 来维护概念完整性，我有的时候跟别人讲，你别复制代码，这是给别人在埋雷，
听都没人听，国内大环境的情况下，在这些人为带来的复杂性未得到根治前，
使用 DDD 去管理因为业务本身逻辑带来的复杂性，可以说是毫无意义。

@ExiFeng ok ，感谢感谢