写点什么

DDD

64 人感兴趣 · 158 次引用

  • 最新
  • 推荐

项目终于用上了 DDD 领域驱动,太强了!

在公司对支付业务、结算业务、资金业务使用DDD进行领域建模的两年,得到了许多好评,也面对过不少质疑,总体来说还是能收获不少,这对团队成员理解业务起着很大作用。近半年一直在研究DDD的落地实战,如今已修得阶段性成果,迫不及待与大家分享我的落地经验。

https://static001.geekbang.org/infoq/07/079efddc31d0fae1c31a081bf72a11b7.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

浅谈复杂业务系统的架构设计 | 京东云技术团队

复杂系统的架构设计不是一蹴而就的,合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。

https://static001.geekbang.org/infoq/07/079efddc31d0fae1c31a081bf72a11b7.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

关于聚合根,领域事件的那点事 --- 深入浅出理解 DDD | 京东云技术团队

本文通过小demo的方式跟大家分享一下我对DDD中战术层级的理解,算是抛砖引玉,该理解仅代表我个人在现阶段的一个理解,也可能未来随着业务经验深入,还会有不同的理解。

国外顶级架构师编写 2580 页 DDD 领域驱动设计笔记, 看到内容后破防了

随着分布式技术的快速兴起,我们已经进入到了微服务架构时代。微服务架构的出现,很好地实现了应用之间的解耦,解决了单体应用扩展性和弹性伸缩能力不足的问题。随着业务的复杂度升级,其好处自然不言而喻。

https://static001.geekbang.org/infoq/84/84e52f9a38e4de57af15e827635b31da.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

【架构与设计】常见微服务分层架构的区别和落地实践

软件工程的方方面面都遵循一个最基本的道理:没有银弹,架构分层模型更是如此,每一种都有各自优缺点,所以请根据不同的业务场景,并遵循简单、可演进这两个重要的架构原则选择合适的架构分层模型即可。

真下饭!字节技术官 DDD(领域驱动设计)手册,拆解业务代码首选

至少20年前,一些顶尖的软件设计人员就已经认识到领域建模和设计的重要性,但令人惊讶的是,这么长时间以来几乎没有人写出点儿什么,告诉大家应该做哪些工作或如何去做。尽管这些工作还没有被清楚地表述出来,但一种新的思潮已经形成,它像一股暗流一样在对象

https://static001.geekbang.org/infoq/08/087f7d218fa75b829f26a2a66fea1b00.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

从 MVC 到 DDD 转变过程中的一点碎碎念

最近再看《三体》电视剧,开篇就演很多科学界的大V,叫嚣着“物理学不存在了”,然后自杀。。。

https://static001.geekbang.org/infoq/ea/eae6ffd6bec865e9a1f6e9ab9592c1e8.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

聊一聊,我对 DDD 的关键理解

当我们在学习DDD的过程中,感觉学而不得的时候,可能会问:我们还要学么?这的确引人深思。本文基于工作经验,尝试谈谈对DDD的一些理解。

https://static001.geekbang.org/infoq/4d/4d79b4d6547dfa856f666e4e1f82a814.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

《解构领域驱动设计》- 软件复杂度解析

用户头像
珑彧
01-04

复杂系统是由大量相互作用的部分组成的系统。与整个系统比起来,这些组成部分相对简单,没有中央控制,组成部分之间也没有全局性的通信,并且组成部分的相互作用导致了复杂行为。

如何使用 DDD 进行设计

用户头像
SkyFire
2022-12-18

DDD(领域驱动设计)是一种软件设计方法论,旨在帮助开发人员更好地理解和解决业务问题。它通过将业务领域的概念映射到软件架构来实现这一目的。

https://static001.geekbang.org/infoq/b6/b6b9a4710d9a84964ceb0e1410a58272.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

面向场景级的业务资产沉淀和开放

用户头像
原力在线
2022-12-03

随着业务场景的不断丰富,复杂度也会随之急剧变大。在场景细节发生变化时,我们不希望这层的改变会影响到业务实体、UI等。如果一个场景没有进行很好的抽象,就很难做到不同场景的逻辑隔离以及场景级复用。

https://static001.geekbang.org/infoq/af/af31d8fc5f0c867aa40d75f7ffc90743.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 与 EDA- 核心逻辑提炼方法论

用户头像
胖子笑西风
2022-11-29

领域设计可能需要大家在观念上有所转变,现在大多数开发都属于业务开发,业务开发最重要的不是说对一些基础设施了解的有什么深入,而是应该对你所属的行业了解到一定程度,能够刻画你所属的行业的核心业务逻辑。

https://static001.geekbang.org/infoq/3b/3b5e212443f02dce70294c4fefe366e5.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

CQRS 与 Event Sourcing

用户头像
胖子笑西风
2022-11-18

像之前讲六边形架构一样,CQRS的核心在于首尾的标准化。抽离出来的命令与事件最好不要改变。这样可以保证核心领域的业务逻辑不变。Event Sourcing讲的是Event的溯源,但有时候,溯源是要到Command的,所以有时候,我们也需要把Command存储起来。

https://static001.geekbang.org/infoq/06/068e6cff0aea022c09004705a8d0f60d.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 与应用架构

用户头像
胖子笑西风
2022-11-18

应用架构的存在,是了使一个应用的代码从混乱变得有序。尤其在多人参与开发的情况下,人数越多,熵越大。整洁有序的架构可以缓解熵增,但阻止不了,绝大部分的软件开发经过一段时间之后,都很难保持整洁。

https://static001.geekbang.org/infoq/6d/6d6d35314238cbd91166de799f94d15b.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 建模案例分享

用户头像
Bright
2022-10-09

前面的文章《我理解的 Smart Domain 与 DDD》分析了 Smart Domain 的设计。虽然 Smart Domain 作为一种设计范式,可以辅助实现 DDD。但是具体到项目,建模还得结合实际领域问题,深入思考,大量尝试,大声建模,才能得到好的模型。有哪些值得参考的案例呢?

https://static001.geekbang.org/infoq/01/0121d86f0dcfa414ef4cfa645a82f3e7.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

对领域驱动设计的理解与社交领域的实践

用户头像
2022-09-25

在设计和实现一个系统的时候,这个系统所要处理问题的领域专家和开发人员以一套统一语言进行协作,共同完成该领域模型的构建,在这个过程中,业务架构和系统架构等问题都得到了解决,之后将领域模型中关于系统架构的主体映射为实现代码,完成系统的实现落地。

https://static001.geekbang.org/infoq/22/22eeb11100c170a032567ef19290f8af.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

用 TDD 开发基于数据库的长时任务系统

用户头像
Bright
2022-09-04

在最近的一个项目上,我们再次碰到了需要处理长时任务的场景。 以下场景均可看作长时任务场景:1. 在 GitHub 提交了一个 PR,要分别向上百个相关用户单独发送邮件 2. 用户上传了一个文件,需要扫描这个文件是不是带病毒 3. 用户...

https://static001.geekbang.org/infoq/27/27c8919c60781ee8aa4bff22420c556e.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

好代码的五个特质 -CUPID

用户头像
Bright
2022-09-04

新的一期技术雷达如期发布,仔细阅读了这一期的所有条目,CUPID这一条尤其让我产生共鸣。CUPID出自Daniel的一篇名为《CUPID—for joyful coding》的博文,即《CUPID-为了快乐编程》。CUPID是Composable/Unix philosophy/Predictable/Idiomatic/Domain based

https://static001.geekbang.org/infoq/26/26660e026739a6d5989d17fd9e420574.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

我理解的 Smart Domain 与 DDD

用户头像
Bright
2022-09-04

前段时间,咱们CTO八叉在极客时间做了一次关于用Smart Domain实现DDD的分享。一个新词Smart Domain进入大家的视野。 Smart Domain是啥?为什么可以用Smart Domain实现DDD?本文尝试结合以往对DDD的学习和实践的经验,跟大家分享一下个人的理解。

https://static001.geekbang.org/infoq/54/54f7da7848429fdb5fff9a0e8eb296ee.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 实战 (12- 终篇):DDD 下微服务的“分分合合”及一个倡议

用户头像
深清秋
2022-08-23

在前面的《DDD 实战 (6):战略设计之技术决策》中,我曾经提到“微服务随时可拆可分”。本篇就来演示“微服务的随时可拆可分”这一DDD编程特性。同时,这将是本系列的最后一篇文章。

https://static001.geekbang.org/infoq/77/77b58e93c12085c6d417359761a260a7.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

迄今为止最完整的 DDD 实践

用户头像
阿里技术
2022-08-18

对于一个架构师来说,在软件开发中如何降低系统复杂度是一个永恒的挑战。本文将为大家介绍DDD(领域驱动设计)及最佳实践。

转转价格系统 DDD 实践

领域驱动设计,不仅带给我们一套新的概念,还提供了一套全新的设计思路,应用在构建大型复杂软件系统之上。客观的理解它、应用它,能让它发挥出最大的作用。

.NET 现代应用的产品设计 - DDD 实践

我们将通过DDD完成业务与技术的完整落地

https://static001.geekbang.org/infoq/24/240d40afbe5eda6c02ba88567956d4a6.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 领域驱动设计如何进行工程化落地

前面文章中重点围绕如何通过战略设计与战术设计进行DDD领域模型分析以及沉淀,但是还没有涉及到工程层面的落地。所有的这些架构理论或者设计模式到最后都是为了让我们的代码结构更加清晰,扩展性以及维护性

https://static001.geekbang.org/infoq/54/54f7da7848429fdb5fff9a0e8eb296ee.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 实战 (11):冲刺 1 代码 TDD 实现之道

用户头像
深清秋
2022-07-10

在本篇中,我将首先介绍TDD三重奏(写测试-写功能-重构)和相关原则,然后用实际代码演示TDD的工作流程,最后我会讲到编程过程中采用哪些技巧处理一些现实的技术细节问题。

https://static001.geekbang.org/infoq/72/72501cb853353b7573a3fbf4785c117c.png?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 概念复杂难懂,实际落地如何设计代码实现模型?

今天我接着跟大家聊一聊,DDD概念复杂难懂,实际落地如何设计代码实现模型。或许你是刚看到关于这部分的内容,想着这里我有必要多说一句,关于这个话题,框架上,分为这样两部分讲的:方法篇 + 实践篇。

https://static001.geekbang.org/infoq/00/0069aa5d066ce5cbea24caab53102ff5.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 是个何许人也

用户头像
卢卡多多
2022-06-14

微服务设计为什么要选择DDD?

https://static001.geekbang.org/infoq/54/54f7da7848429fdb5fff9a0e8eb296ee.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 实战 (10):冲刺 1 战术之服务设计(下)及技术决策

用户头像
深清秋
2022-05-10

本篇完成sprint1 剩下的服务设计(主要是商品上下文),以及战术设计中需要进行的技术决策(这个只有第一次冲刺才需要)。

https://static001.geekbang.org/infoq/54/54f7da7848429fdb5fff9a0e8eb296ee.jpeg?x-oss-process=image%2Fresize%2Cw_416%2Ch_234

DDD 实战 (9):冲刺 1 战术之服务设计(上)

用户头像
深清秋
2022-05-01

本篇完成sprint1的服务设计的主要部分(鉴权上下文、订单上下文)。这里说的“服务”其实是前面第7篇中识别出来的“服务功能”。这里服务设计将遵循第7篇中已经列出的服务契约来进行。

DDD_DDD技术文章_InfoQ写作社区