DDD
64 人感兴趣 · 158 次引用
- 最新
- 推荐
项目终于用上了 DDD 领域驱动，太强了！
在公司对支付业务、结算业务、资金业务使用DDD进行领域建模的两年，得到了许多好评，也面对过不少质疑，总体来说还是能收获不少，这对团队成员理解业务起着很大作用。近半年一直在研究DDD的落地实战，如今已修得阶段性成果，迫不及待与大家分享我的落地经验。
浅谈复杂业务系统的架构设计 | 京东云技术团队
复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。
关于聚合根，领域事件的那点事 --- 深入浅出理解 DDD | 京东云技术团队
本文通过小demo的方式跟大家分享一下我对DDD中战术层级的理解，算是抛砖引玉，该理解仅代表我个人在现阶段的一个理解，也可能未来随着业务经验深入，还会有不同的理解。
【架构与设计】常见微服务分层架构的区别和落地实践
软件工程的方方面面都遵循一个最基本的道理：没有银弹，架构分层模型更是如此，每一种都有各自优缺点，所以请根据不同的业务场景，并遵循简单、可演进这两个重要的架构原则选择合适的架构分层模型即可。
如何使用 DDD 进行设计
DDD（领域驱动设计）是一种软件设计方法论，旨在帮助开发人员更好地理解和解决业务问题。它通过将业务领域的概念映射到软件架构来实现这一目的。
CQRS 与 Event Sourcing
像之前讲六边形架构一样，CQRS的核心在于首尾的标准化。抽离出来的命令与事件最好不要改变。这样可以保证核心领域的业务逻辑不变。Event Sourcing讲的是Event的溯源，但有时候，溯源是要到Command的，所以有时候，我们也需要把Command存储起来。
DDD 建模案例分享
前面的文章《我理解的 Smart Domain 与 DDD》分析了 Smart Domain 的设计。虽然 Smart Domain 作为一种设计范式，可以辅助实现 DDD。但是具体到项目，建模还得结合实际领域问题，深入思考，大量尝试，大声建模，才能得到好的模型。有哪些值得参考的案例呢？
对领域驱动设计的理解与社交领域的实践
在设计和实现一个系统的时候，这个系统所要处理问题的领域专家和开发人员以一套统一语言进行协作，共同完成该领域模型的构建，在这个过程中，业务架构和系统架构等问题都得到了解决，之后将领域模型中关于系统架构的主体映射为实现代码，完成系统的实现落地。
用 TDD 开发基于数据库的长时任务系统
在最近的一个项目上，我们再次碰到了需要处理长时任务的场景。 以下场景均可看作长时任务场景：1. 在 GitHub 提交了一个 PR，要分别向上百个相关用户单独发送邮件 2. 用户上传了一个文件，需要扫描这个文件是不是带病毒 3. 用户...
好代码的五个特质 -CUPID
新的一期技术雷达如期发布，仔细阅读了这一期的所有条目，CUPID这一条尤其让我产生共鸣。CUPID出自Daniel的一篇名为《CUPID—for joyful coding》的博文，即《CUPID-为了快乐编程》。CUPID是Composable/Unix philosophy/Predictable/Idiomatic/Domain based
我理解的 Smart Domain 与 DDD
前段时间，咱们CTO八叉在极客时间做了一次关于用Smart Domain实现DDD的分享。一个新词Smart Domain进入大家的视野。 Smart Domain是啥？为什么可以用Smart Domain实现DDD？本文尝试结合以往对DDD的学习和实践的经验，跟大家分享一下个人的理解。
DDD 实战 (12- 终篇)：DDD 下微服务的“分分合合”及一个倡议
在前面的《DDD 实战 (6)：战略设计之技术决策》中，我曾经提到“微服务随时可拆可分”。本篇就来演示“微服务的随时可拆可分”这一DDD编程特性。同时，这将是本系列的最后一篇文章。
转转价格系统 DDD 实践
领域驱动设计，不仅带给我们一套新的概念，还提供了一套全新的设计思路，应用在构建大型复杂软件系统之上。客观的理解它、应用它，能让它发挥出最大的作用。
DDD 领域驱动设计如何进行工程化落地
前面文章中重点围绕如何通过战略设计与战术设计进行DDD领域模型分析以及沉淀，但是还没有涉及到工程层面的落地。所有的这些架构理论或者设计模式到最后都是为了让我们的代码结构更加清晰，扩展性以及维护性
DDD 实战 (9)：冲刺 1 战术之服务设计（上）
本篇完成sprint1的服务设计的主要部分（鉴权上下文、订单上下文）。这里说的“服务”其实是前面第7篇中识别出来的“服务功能”。这里服务设计将遵循第7篇中已经列出的服务契约来进行。
