首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何用 DDDDDD 建模,破解 DDD 的魔法?

回到标题上,我们用 DDDDDD 进行建模,只是我们想到的解决方案之一,而不是问题。先再回到上面的问题上, DDD 要解决什么问题 —— 如何将复杂问题控制到人能处理的范围?...而我们想做的是:如何实现 DDD 设计与代码实现的双向绑定?于是乎,DSL 与双向图形化便是我们想到的解。所以,作为解决方案的第一步,那便是对 DDD 进行建模,以进行 DDD 的图形生成。...统一 DDD 的统一语言 尽管,我司(Thoughtworks)会在各类的 DDD 工作坊中强调,统一语言的重要性。...于是乎,这里,我们采用 DDD 社区给出了一个详细的《DDD 概念参考》,作为我们构建 DDD 的统一语言的基础。...与得到一个有用的结果相比,在过程中对于 DDD 的抽象,构建 DDDDDD 模型,显得更有意思。

86420
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    DDD开篇

    从知道DDD到现在已经很多年了,看了不少理论知识,在项目中也使用了DDD,碰到些问题,也有些思考,整理一下,上升一下,形成一种适合自身的方法论 在回顾过程中,首先追根溯源,什么是DDD?...为什么要使用DDD?...如何给别人阐述这些最基本的概念与理念,真是个难题 什么是DDD DDD已经发展了很多年,现在的一些书也已经不太关注这个基本概念, 平时闲聊时,开口闭口都是DDD,已经不知道DDD的本体是什么,只是听得耳熟...,说得顺口了,细细回想下,DDD是个什么?...模型是团队在组织领域知识和辨别最感兴趣的原理时一致同意的方式 方法论 由上文可知DDD是一种开发方法,那在DDD之前,是怎么进行软件分析设计的呢?

    65120

    DDD分层

    引起技术实现发生变化的原因与引起领域逻辑发生变化的原因显然不同,这就导致基础设施和领域逻辑问题会以不同速率发生变化 每一层都有各自的职责,显然这也是符合SRP的 如何分层 DDD的标准形态 ?...这样有些另类,所以暂时先把repository全部放在了service层 迷思: 1、基于mybatis的实现,mapper本身是接口,repository实现类放在domain层,不要接口,这样满足DDD...分层规则,但离DIP差了一步 2、在《DDD之熵》中提过 DDD引入repository放在了领域层,一是对应聚合根的概念,二是抽象了数据库访问,,但DDD限界上下文可能不仅限于访问数据库,还可能访问同样属于外部设备的文件...有几种设计思路 ui层完全归属于大前端,不在后端,也就不在ddd中,后端都是从application service开始 controller归于ui controller归于infra,controller...防腐层(ACL)放在下游,将上游的消息转化为下游的领域模型 结合generator-assist-dao模块的问题,是否可以扩大ACL,而不仅限于gateway中,像资源库一样,不必完全遵循DDD只抽象

    2.4K20

    DDD模型初探

    背景 面试官: DDD模型知道吗? 了不起: 知道,DDD叫领域驱动设计。 面试官: 在实际项目中使用过吗? 了不起: 没有使用过 面试官: 如果要求你用DDD来设计一个订单系统, 你会这么设计?...通过以上步骤,我们可以使用DDD来设计和实现订单模块,从而提高软件开发的效率和质量。...总结 总结一下DDD方式的优缺点以及我们什么场景下采用DDD 优点: 更好地理解业务领域:DDD可以帮助我们更好地理解业务领域,将业务逻辑和技术实现分离,从而提高软件开发的效率和质量。...更好地支持变化:DDD可以帮助我们更好地支持变化,将变化隔离在领域模型内部,从而降低变化对系统的影响。 缺点: 学习成本高:DDD需要掌握一定的领域知识和技术实现,因此学习成本较高。...设计复杂度高:DDD需要进行领域建模和设计,因此设计复杂度较高。 实现难度大:DDD需要进行领域驱动的实现,因此实现难度较大。 适用场景: 需要处理复杂业务逻辑的系统。 需要支持变化的系统。

    35320

    DDD有感

    领域驱动设计 Domain-driven design,缩写DDD,是对业务的抽象,把业务模型反形成系统架构设计的一种方式。通过数据对象解决业务问题。...模型对象代码规范 Data Object:DO、数据对象,在DDD的规范里,DO应该仅仅作为数据库物理表格的映射,不能参与到业务逻辑中。...DDD结构一 分层: Application层 Domain层 Infrastructure层 User Interface为用户界面层(或表示层),负责向用户显示信息和解释用户命令。...DDD Repository代码规范 传统Data Mapper(DAO)属于“固件”,和底层实现(DB、Cache、文件系统等)强绑定,如果直接使用会导致代码“固化”。...应该避免所谓的“通用”Repository模式 DDD的开源应用项目 DDD的开源应用项目

    42950

    DDD之Repository

    之前的DDD文章中也指出过,现在从理论角度对于repository是错误,但一直没有摸索出最佳实践,都是当DAO使用,区别在于repository是领域层,也没有深入思考过 最近再次温习《DDD第二弹》...虽然具体的技术细节有所不同,但问题仍然存在--客户处理的是技术,而不是模型概念 在DDD思想中,领域模型是最重要的,所有的一切手段都是为了让团队专注于模型,屏蔽一切非模型的技术细节,这样也才能做到通用语言...,交流的都是模型 VS DAO 有人总结DDD就是分与合,分是手段、合是目的;对于DDD战略来讲,就是通过分来形成各个上下文界限,在各个上下文中,再去合,很类似归并算法 而聚合就是最小的合,repository...有个很简单的办法区分,业务规则是有if/else的,业务流程没有 作者这样回答,我还是觉得太抽象了,在domain service拿数据太常见,还在看DDD第四讲时,作者有个示例是用domain service...对任何工具的使用都需要多方位权衡 《DDD第二弹》中也提到 业界有两个主流的变更追踪方案:这两个方案只是上面两种方案另取的两外名字而已,意思是一样的 1.基于Snapshot的方案:当数据从DB里取出来后

    1.2K20

    DDD之Repository

    之前的DDD文章中也指出过,现在从理论角度对于repository是错误,但一直没有摸索出最佳实践,都是当DAO使用,区别在于repository是领域层,也没有深入思考过 最近再次温习《DDD第二弹》...虽然具体的技术细节有所不同,但问题仍然存在--客户处理的是技术,而不是模型概念 在DDD思想中,领域模型是最重要的,所有的一切手段都是为了让团队专注于模型,屏蔽一切非模型的技术细节,这样也才能做到通用语言...,交流的都是模型 VS DAO 有人总结DDD就是分与合,分是手段、合是目的;对于DDD战略来讲,就是通过分来形成各个上下文界限,在各个上下文中,再去合,很类似归并算法 而聚合就是最小的合,repository...有个很简单的办法区分,业务规则是有if/else的,业务流程没有 作者这样回答,我还是觉得太抽象了,在domain service拿数据太常见,还在看DDD第四讲时,作者有个示例是用domain service...对任何工具的使用都需要多方位权衡 《DDD第二弹》中也提到 业界有两个主流的变更追踪方案:这两个方案只是上面两种方案另取的两外名字而已,意思是一样的 基于Snapshot的方案:当数据从DB里取出来后,

    7.9K22

    DDD领域驱动设计落地实践系列:初识DDD

    从本文开始笔者将通过一系列的文章阐述自己对于DDD的理解以及如何在项目实战中落地实践DDD。本文作为系列文章的开端,主要和大家聊聊DDD的一些基本概念以及使用背景。 DDD到底是何方神圣?...DDD 上文中通过不同软件设计方式的描述,引出了DDD领域驱动设计模式,那么我们就来看下DDD到底是什么。所谓DDD即Domain Driven Design,字面意思就是领域驱动设计。...想要真正的落地实施DDD必须满足以下两个条件 1、统一认识:DDD不是谁的独角戏,需要整个团队自上而下对于DDD有比较深刻的理解以及认同。...DDD没有大规模应用的原因。...DDD的价值 通过上文的描述,我们大概知道了为什么需要使用DDD来实现软件架构设计。那么DDD会给我们带来怎样的价值呢?

    51630

    DDD这样落地

    本想搞场chat,可失败了,那就失败吧,也许现在DDD的热度凉了,眼球都到低代码了,对于低代码,我现在只有使用权,还没有发言权,也许明年能写写 DDD意义 每种理论的诞生都是站在前人的基础之上,总得要解决一些痛点...;DDD自己标榜的是解决复杂软件系统,对于复杂怎么理解,至少在DDD本身理论中并没有给出定义,所以是否需要使用DDD并没有规定,事务脚本式编程也有用武之地,DDD也不是放之四海皆准,也就是常说的没有银弹...在这张方法融合论里面,DDD只是一小块,为什么要心中充满DDD呢,不都是进阶路上的垫脚石。...任何事物都是过犹不及,如文章开头所述,没有银弹,千万别因为DDD的火热而一股脑全身心投入DDD,不管场景是否适合,都要DDD;犹如设计模式,后面出现了大量的反模式。...错误的抽象比没有抽象伤害力更大 DDD分层 ?

    1.6K61

    DDD实现之路

    ---- DDD之战略设计 需要指出的是,DDD绝非一套单纯的技术工具集,但是我所看到的很多程序员却的确是这么认为的,并且也是怀揣着这样的想法来使用DDD的。...过于拘泥于技术上的实现将导致DDD-Lite。简单来讲,DDD-Lite将导致劣质的领域对象,因为我们忽略了DDD战略建模所带来的好处。...这不是DDD的做法,DDD有限界上下文将这两个不同的概念区分开来。...---- 总结 DDD存在战略设计和战术设计之分,过度地强调DDD的技术性将使我们错过由战略设计带来的好处。因此,在实现DDD时,我们应该将战略设计也放在一个重要的位置加以对待。...DDD的战术设计则更加侧重于技术实现,它向我们提供了一整套技术工具集,包括实体、值对象、领域服务和资源库等。虽然DDD的概念已经提出近10年了,但是在如何实现DDD上,我们依然有很长的路要走。

    44320
    领券