01｜DDD小传：领域驱动设计为什么这么火？
DDD 说的是什么？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计（DDD）是一种系统化的软件开发方法学和思想，强调领域建模的重要性，将面向对象方法学和敏捷软件开发进行总结和提炼，使之更易学习和实践。DDD通过模式的方法，提炼出一套围绕领域建模进行软件开发的模式，强调业务人员和技术人员的协作，以及系统的柔性设计和演进。虽然DDD在早期并未受到广泛关注，但随着数字化时代的到来和相关技术的普及，如微服务架构和敏捷软件开发，DDD逐渐成为解决复杂软件开发问题的重要方法。现在，DDD已经成为软件开发领域的热门话题，为开发者提供了应对复杂业务问题的新思路和方法。
《手把手教你落地 DDD》，新⼈⾸单¥59
全部留言(33)
- 最新
- 精选
骆驼、置顶1、我觉得DDD的出现是为了应对业务需求多变的场景，它将业务划分为不同领域，同一类业务形成一个领域聚集在一起，不同业务相互隔离，当需求变更时，只需要变动业务对应的领域部分即可，一般都是结合设计模式进行开发，保证系统的可维护性，另外在代码层面上体现在尽可能的减少代码之间的耦合，避免牵一发而动全身。而微服务在我看来是一种系统架构设计，他的出现是主要为了解决单体应用无法支撑高并发的业务场景，但是微服务如何划分一直没有一个明确的概念，而DDD领域划分的思想就与微服务的划分相一致，这就导致DDD是微服务划分的一种重要手段。但是这里面如果DDD领域划分的过于细致，就会导致微服务的数量就会增多，对于一般企业而言没有那么多的资源去维护这种情况，我也不知道该咋解决。 2、对于我来说DDD应该算是创新，毕竟工作5年了，之前接触过的项目一直采用的是MVC模式开发，很多地方一开始设计的可能很好，随着开发时间的推移，到后来却越来越难维护，有的时候改一行代码，其他的地方就出问题了，耦合性太强，结果不得不导致重新写代码了。而DDD就明确要求各领域之间相互隔离，不能直接引用，就自然而然的解耦了作者回复: 很多要点您都说得不错。有一点要澄清一下，作为微服务划分依据的，是“限界上下文”而不是领域。等到后面学到限界上下文，我再说说它和领域、子域的关系。 关于您指出的微服务粒度过细的问题，确实很常见，这一点也会在后面讲限界上下文的时候讨论。现在先说一点，就是微服务的粒度可以参考团队的“认知边界”。您可以先琢磨琢磨。
2022-12-07归属地：广东25
escray置顶
其实我有一点怀疑 DDD 现在很”火“这个说法，在 Google trends 上可以看到 DDD 的热度不及 2004 年高峰时的一半，另外就是似乎在国内相对热度比较高。 还是打算认真的学习一下 DDD，看能否在理解业务和编写代码上有所帮助。 DDD 的目的显然不是为了开发微服务，可能两者背后有一些相同的想法，DDD 出现的早，而微服务大概要晚十多年的样子。DDD 是”开发复杂软件的系统化方法学和思想“，微服务显然不是。 我觉的 DDD 可以算是创新，但是更有价值的可能是通过 DDD 的方法论建立起来的领域模型。作者回复: 是的，DDD是方法学层面，微服务是架构风格层面。DDD抽象于具体的架构风格。DDD可以帮助设计微服务，但不仅仅用于微服务。领域模型确实是DDD中最有价值的部分之一。
2022-12-06归属地：广东23
Jxin置顶1.不同意。时间线上先后倒置，所以至少 Evans 不会是为了微服务而ddd；时代在变化，ddd的“目的”也可能变化（也许就是因为解决了微服务拆分这个问题才火起来的呢，哪怕跟初衷不一样了，但价值高呀）。但我不这么认为，因为哪怕是现在，也不是所有公司都适合引入微服务(技术基础不具备/组织结构不匹配/业务特性不需要), 但大部分业务领域（特殊规则非事件流的还是搞不定，比如特定的复杂计算公式）都可以用ddd来提炼和构建认知，两者间是解偶松散的。所以能够支撑微服务拆分可能是ddd被挖坟的起因，但不是它能站住脚的全部因素，ddd的目的就是为了开发为服务总归有些片面。 2.定个调，软件设计的创新就是提高长期迭代的效率。ddd目前能看到一些成果（至少咨询公司能卖了不是），所以能说它是一种创新。但这个成果不多，因为没有大杀器级别的软件产品来证实（仅靠咨询公司的瓶颈），所以创新得可能没有那么突出。作者回复: 1.关于微服务的回答很到位呀。微服务是一种架构风格（或者说架构模式）；DDD是方法学层面，抽象于具体的架构风格。微服务固然用得上，单体也用得上，无服务器架构也成，或者将来才出现的某种架构风格，说不定也行。 2.你先给出了“创新”的评价标准，然后再评价DDD，说明了思维的严谨。等我们听听更多同学的意见，再归纳一下。 关于“挖坟”嘛，广东人更喜欢说“咸鱼翻生” 😊
2022-12-06归属地：广东2
业余草置顶尽信DDD不如不用DDD。 DDD不能算一门完善的理论，它是出自工程师之手，目前还只能算是经验的总结和模式的梳理（当然，DDD思想也在不断完善中，例如“事件风暴建模法”是后面才引入到DDD核心内容中的），它能解决的问题是针对业务复杂性如何优化软件的架构。 对于性能问题以及代码细节上的结构问题，它并不能提供足够的帮助。所以当我们在应用DDD的时候，如果发现它并没有把我们的代码变成“完美的”、“理想化”的代码，反而造成了一些麻烦，不妨审视一下，我们是否已经过渡依赖了DDD，对它寄予了过大的期望。 反之，如果以平常心来对待DDD，和Eric Evans一样，把它当成一套模式的集合，发现哪个模式对我们有用就拿来用一下，不能用也不要勉强(DDD的限界上下文、聚合、实体、值对象等等，都可以认为是一种模式)，以这种拿来主义的心态去使用DDD，反而可能会渐入佳境，也不会造成太大负担。作者回复: “尽信DDD不如不用DDD”这句说的很棒。提到模式，说明您肯定是看过原书的。事件风暴虽然在课里面也讲得比较细，但可能还算不上DDD的核心。关于DDD对代码的影响，确实不会特别细，但可能比一般同学想象的要“细”。DDD和整洁代码结合，就非常好了。等课程讲到代码的时候，我们再探讨。
2022-12-06归属地：广东331- Geek_d1bbb01、感觉DDD是一种软件设计方法，微服务是一种软件架构方式 2、DDD是对过去软件设计方法的改良。
作者回复: 说的很好！ 关于“软件设计方法”，我再补充两句。“设计”有广义狭义之分。狭义的设计，是与“分析”相对而言的，例如系统设计、架构设计、代码设计等等；广义的设计，包含了分析和狭义的设计，泛指给出一个需求，得到解决方案的过程。“领域驱动设计”中说的设计，是广义的设计。
2022-12-06归属地：广东5 
bighero1.DDD的目的：DDD出现应该追溯到2004年，那是个单体架构盛行的年代。很多逻辑处理不在应用层，而是在数据库层。而且面向对象也刚刚行成大气候，但是开发大项目单体业务应用，却还非常繁杂，逻辑复用性差等问题。DDD的出现主要是为了上浮业务逻辑从数据库层到应用层 达到高内聚低耦合目的而建立的一些业务领域的oo原则。 2.DDD它是一种实践方法论。不可否认它是一种创新。它的创新在老oo的基础上进行的一种创新方法论。它首次大胆的提出了限界上下文这一方法论，这是oo一切对象复杂网络关系的大胆切割。大有“庖丁解牛，目无全牛”的艺术与哲学感。如果说oo仅仅是技术，那么分了限界才算接近了“道”。也是“技近乎于道”的一种体现。又怎能不说是种创新创举。作者回复: DDD是方法学层面，微服务是架构风格层面，同样的方法学可以用于不同的架构风格。 关于创新，您的回答最富诗意呀。
2022-12-07归属地：广东4
aoe《领域驱动设计：软件核心复杂性应对之道》开始没几页作者就说：好的模型是改出来的。 看到这里我想到了 TDD，不然没人敢改代码 从编码实现的角度看：没有 TDD 很难 DDD作者回复: 最好再结合重构、持续集成、迭代开发等实践。
2022-12-07归属地：广东3
赫伯伯DDD 适合一线产品经理或者业务分析师学习，近距离接触客户，才能理解业务。除非工程师是驻场的，否则在大后方就别妄图理解和应用 DDD 了作者回复: 产品经理和客户聊需求时，一般不会用到领域模型。领域模型用在产品经理和开发团队，尤其是架构师的沟通。
2023-06-08归属地：河北2
Jays10年前第一次接触DDD相关概念时，顿时就解答了「为什么平时写的代码看起来那么别扭」，首当其冲就是当时泛滥成灾的「贫血模型」和「事务脚本」等。DDD是很棒的方法论，虽然落地很难，但我认为这个方向是对的，它能使OO done right.作者回复: 祝成功！
2022-12-22归属地：广东2
不记年DDD我觉得主要解决了以前的软件工程理论中留下的两个问题 一个是业务与技术关系的关系， 提供一系列方法，以业务为出发点，构建技术解决方案 一个是与非技术人员的协作问题，提供一些列方法，实现技术员与各个其他岗位的有机的协作作者回复: 协作确实是一个核心点
2022-12-16归属地：广东2
