首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏互联网技术栈

    领域驱动模型(DDD

    什么是领域驱动模型? ),简称Evans DDD领域驱动设计思想进入软件开发者的视野。 而在业务知识梳理的过程中,我们必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计的基本概念。而领域驱动设计的核心就在于建立正确的领域驱动模型。 ? 当系统越来越复杂时,开发时间指数增长,维护成本很高 DDD设计思想 采用DDD的设计思想,业务逻辑不再集中在几个大型的类上,而是由大量相对小的领域对象(类)组成,这些类具备自己的状态和行为,每个类是相对完整的独立体 DDD开发案例 超市收银业务 领域驱动设计在互联网业务开发中的实践 本文作者是组内同事 杜宁,目前负责美团外卖活动管理模块业务。

    4.2K11发布于 2018-12-12
  • 来自专栏_春华秋实

    了解 DDD 领域驱动设计

    ,架构思想也清晰简单 难点:使用面向对象编程、对领域建模,牵扯到很多的新概念和方法论,在项目中使用需要经验 三层架构有什么可以吸取 DDD 的经验吗? 常见的编程范式包括面向对象编程、函数式编程、命令式编程等 DDD领域驱动设计,Domain-Driven Design)应用架构:一种软件开发方法论,强调以业务领域模型为核心,通过领域模型紧密协作来构建复杂系统的架构 DDD 架构和三层应用架构对比 核心代码位置的不同 在 DDD (领域驱动设计) 中,需要将重点放在领域层(Domain Layer)进行业务逻辑和规则的实现。 三层架构中业务逻辑都堆积在 Service 层 编程范式的不同 领域驱动中使用了面向对象和 命令式编程两种方式 通过面向对象抽象领域模型 通过命令式编程,编排业务逻辑 三层架构中使用过程式编程(命令式编程 现在再来看这张DDD的典型架构图,你可能会更加理解DDD的思想内核,这是一种面向领域的设计方法,把领域层(业务规则)包在最里面,保护好边界,避免领域层被污染。

    38820编辑于 2025-01-22
  • 来自专栏Java技术圈子

    DDD领域驱动设计初探

    欢迎批评指正 DDD 强调领域模型要兼顾业务和技术两个视角。 我们怎么用一套系统化的方法,抽丝剥茧、一步一步地把需求落实到代码呢?咱们看看下面这张图,它表示了领域驱动设计中的主要流程。 1 领域驱动设计主要的开发流程你可以看到,在整个开发流程中,首先是要捕获行为需求,也就是传统软件工程里的“获取需求”。 而 DDD 分层架构,通常说的是进程内架构。 然后就可以根据领域模型进行数据库设计,最后是代码实现。 这样,就形成了一个基于 DDD 的开发闭环。 数据库建表 DDD 主张要根据领域模型来进行数据库设计,保证数据库和领域模型的一致,从而保证数据库和业务需求以及代码的一致性。 5 衡量团队DDD水平 6 其他补充 其实对于DDD来说,是否使用充血模型,只是形式上的区别,关键在于一定要有识别出领域对象,和业务专家统一语言,这样就能无障碍沟通,然后慢慢把这个领域模型推广到整个系统

    70520编辑于 2023-04-10
  • 来自专栏北洋csdn

    领域驱动DDD 业务浅析

    面向过程是对数据的执行流程 ,按照分支条件 ,模式匹配 进行设计面向对象 是对数据的功能,定义出发 重新组织数据,ddd的根基:通用语言和模型驱动的设计通用语言:这里的通用值得并不是技术领域的,而是技术领域和业务领域的通用语言 而ddd要求 先从 领域中有哪些关键事件和结果出发;再从事件和结果出发 思考 做这个事情达成这个结果 要经历哪些行为哪些步骤;再去思考 这些步骤所涉及的概念实体有哪些。 这个步骤正好和面向对象的设计思想相反,面向对象针对的还是数据,但是ddd针对的是领域领域会更加稳定。 2.模型驱动的设计:ddd的模型驱动设计:概念:模型驱动,在ddd里面的模型就是领域模型(一个个业务域),面向对象里面的模型就是对象模型。 组成:领域模型驱动设计,这里的设计有高层和底层设计,对应的就是战略设计和战术设计。我正在参与2023腾讯技术创作特训营第四期有奖征文,快来和我瓜分大奖!

    29620编辑于 2023-12-15
  • 来自专栏若尘的技术专栏

    领域驱动设计(DDD)实践

    不能说微服务拯救了领域驱动设计,但确实是微服务,让领域驱动设计又重新焕发了青春。 DDD 过程 领域驱动设计是一套面对复杂业务进行建模和设计的方法论和实践,建立了以领域为核心驱动力的设计体系。领域驱动设计分为 2 个主要过程:战略设计、战术设计 。 该阶段领域专家只专注于问题域而不是解决方案,业务和技术人员基于 UL 沟通,并且考虑投入产出比,团队只为核心业务进行领域驱动设计并创建UL,订单系统为下单模块进行 DDD,订单监控模块用普通的事务脚本方式来即可 领域驱动设计给出了 DDD分层架构、六边形架构、整洁架构等分层架构,它们遵循“关注点分离”原则,旨在分离和隔离业务复杂度和技术复杂度,凸显了领域模型,保证了领域模型的稳定性和一致性。 领域事件(Repository) 在 Eric 的《领域驱动设计》中并没有提到领域事件,领域事件是最近几年才加入 DDD生态系统的。

    1.1K84发布于 2021-11-23
  • 来自专栏技术那些事

    DDD领域驱动设计实践

    DDD领域驱动设计分为两个阶段: 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型;由领域模型驱动软件设计,用代码来实现该领域模型 ; 由此可见,领域驱动设计的核心是建立正确的领域模型。 )是驱动者,它驱使足球比赛领域中,各个“人”(参与者)的活动。 比如命令部分可以通过领域驱动设计来实现;查询部分可以直接用最快的非面向对象的方式去实现,比如用SQL。

    95050发布于 2021-04-02
  • 来自专栏分母为零

    DDD-领域驱动设计

    DDD-领域驱动设计 参考DDD的设计,DDD官方的架构草图,总体架构分为四层,Infrastructure(基础实施层),Domain(领域层),Application(应用层),Interfaces 在领域驱动设计中根据重要性与功能属性将领域分为三类子域,分别是:核心子域、支撑子域和通用子域。决定产品和企业独特竞争力的子域是核心子域,它是业务成功的主要因素和企业的核心竞争力。 首先确定核心域,确定完核心子域后,根据对这个领域的理解划分出各个上下文,然后根据上下文再确定其他的相关领域。 用DDD走出设计微服务拆分困境 所谓的微服务拆分困难,其实根本原因是不知道边界在什么地方。 而使用DDD对业务分析的时候,首先会使用聚合这个概念把关联性强的业务概念划分在一个边界下,并限定聚合和聚合之间只能通过聚合根来访问,这是第一层边界。

    1.3K10发布于 2019-08-13
  • 来自专栏琦小虾的Binary

    领域驱动设计 (DDD) 总结

    DDD 简述 DDD (Domain-Driven Design),即领域驱动设计是思考问题的方法论,用于对实际问题建模,它以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,然后将这些概念设计成一个领域模型 由领域模型驱动软件设计,用代码来实现该领域模型。所以,DDD 的核心是建立正确的领域模型。 二. 图是表达领域模型最常用的方式,但并不是唯一的表达方式,代码、文字描述也能表达领域模型。 2.2 通用语言 领域驱动设计的一个核心的原则是使用一种基于模型的语言。 /pic/DDD经典分层结构.png)] 上图为经典的领域驱动设计分层架构,图中领域层 (Domain) 的上层是应用层 (Application),下层是基础设施层 (Infrastructure), 上下文图 (Context Map) 参考地址:《【DDD领域驱动设计实践 —— 限界上下文识别》 9.1 上下文图类型 多个系统之间会发生关系,存在交互,这也必然会在各自的限界上下文有所表现。

    3.7K51发布于 2020-07-15
  • 来自专栏爬蜥的学习之旅

    领域驱动设计(DDD)概念入门

    ,即领域服务 领域事件:其它领域关心的发生在当前领域的事件 聚合:一组相关对象的集合,它是数据的修改单元,有自己的聚合根和边界,边界与事务的边界一致,即一个事务只修改一个聚合实例,边界外则一般考虑最终一致性 只为确实需要直接访问的聚合提供资源库,让客户能聚焦于模型 分层模型中使用领域驱动设计 领域驱动设计不需要使用特定的架构,它可以应用于多种架构中,以分层模型为例,一个应用程序可以分成: 用户界面层:处理用户显示和用户请求 ,不包含任何领域和业务逻辑 应用层:很薄的一层,主要用于对领域对象的协调操作,如果使用ACID数据库,它还负责控制事务保证提交的原子性 领域层:处理业务逻辑,并发布领域事件 基础设施层:持久化、消息通信机制等可以重用的基础设施 从而使得状态变更与决策放在展示层,与视图分开,比如某个组件是否可编辑可用true表示可以编辑,而false不可编辑,但是true/false的取值却是有展现层进行赋值 参考 Eric Evans演讲what is DDD Eric Evans演讲bounded context Eric Evans 书 <领域驱动设计-软件核心复杂性应对之道> Vaughn Vernon 书 <实现领域驱动设计> Martin Fowler

    1K20编辑于 2022-03-09
  • 来自专栏架构之家

    领域驱动设计(DDD):领域接口化设计

    所以我们要讨论的是全面接口化,尤其是对领域模型接口化的认识。 领域接口化 通常的情况下我们会把领域模型设计成类(class),但是你有没有想过把领域模型设计成接口(interface)? 具体来说是在持久层使用持久化对象(PO)与领域对象(DO)的之间进行转换。 再过去单机和集群项目与微服务项目是不能兼容的,因为领域模型都是类(class)而不是接口(interface)。 领域模型采用领域驱动设计(DDD)、接口化以及面向对象设计。 总结 领域对象接口化使得我们在内部实现了一套统一的接口,并将领域对象接口化扩展到系统级别时,我们又在系统层次上设计出一套统一地全局接口来开发业务和应对未来变化的环境。

    95410编辑于 2022-07-12
  • 来自专栏小强的进阶之路

    领域驱动设计(DDD):领域和子域

    实现业务其实是在实现所在业务领域 中所需要的业务。技术也是一个领域,称之为技术领域领域驱动设计中的领域 是指的业务领域。 domain-words 百度百科对领域 的解释: 学术思想或社会活动的范围。 具体指一种特定的范围或区域。 《领域驱动设计》中领域指的是一个特定的业务范围 ,大家在这个业务域范围内开展工作。 有关核心域的更多内容请阅读《领域驱动设计》中的第十五章,其中非常详细地阐述了如何明确核心域和实现核心域。 《实现领域驱动设计》中通过问题空间 和解决方案空间 对核心域做了更直接的说明: 问题空间是领域的一部分,对问题空间的开发将产生一个新的核心域。 [DDD, P282] 这两段摘取为我们描述出什么是通用子域 ,从业务域的角度来看,通用子域也是一种业务域,和核心域一样。只是没有核心域的优先级高。

    1.7K40发布于 2021-04-14
  • 来自专栏慕枫技术笔记

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

    引言 笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计,尤其是在业务梳理、中台规划以及微服务划分等方面,DDD是重要的架构设计方法论,对平时的架构设计有非常好的指导作用。 DDD领域驱动设计:我们接触的系统越来越庞大了,涉及的子系统也越来越多了,传统的软件设计方式已经不能满足我们应对复杂系统的设计。 而DDD提供了我们应对大型复杂系统的领域建模以及分析的方法论。 第一种方式咱们就不说了,我们可以来看下数据驱动DDD领域驱动设计。其实这两种设计方式最大的不同就是设计思想的转变。 光靠数据驱动设计难以实现。而DDD关注领域模型,通过领域模型驱动整个系统的软件设计,让那个领域模型与数据模型解耦,明确业务边界,从而能够更好的指导我们完成复杂系统的架构设计。 DDD 上文中通过不同软件设计方式的描述,引出了DDD领域驱动设计模式,那么我们就来看下DDD到底是什么。所谓DDD即Domain Driven Design,字面意思就是领域驱动设计。

    95530编辑于 2023-03-20
  • 来自专栏用户1337634的专栏

    如何开始DDD领域驱动设计

    最近从多种不同渠道了解到DDD领域驱动设计,对复杂业务的设计具有特别好的效果,本人负责的是电商业务的交易系统,正好是很适合的。 那么应该怎么把当前数据库驱动设计切换DDD呢? 数据库设计驱动特点 一般分为Controller, Service和Repository 贫血模型:业务实体类一般都只有getter/setter,不包含任何业务逻辑 复杂的service:业务逻辑都分布在各个 service中 切换 service中的业务逻辑迁移到实体类(形成领域类),充血模型 远程调用怎么处理? 比如订单表和订单商品表的写入 领域类是订单OrderDomain:下单操作后,可以生成两个实体类,分别是订单实体和商品列表实体 参考 设计模式之美:实战一(上):业务开发常用的基于贫血模型的MVC架构违背 如何开始DDD

    60820编辑于 2022-01-12
  • 来自专栏物流IT圈

    领域驱动设计(DDD)理论启示

    不能说微服务拯救了领域驱动设计,但确实是微服务,让领域驱动设计又重新焕发了青春。DDD是一个非常庞大的建模和设计体系,这篇文章只在理论和概念上阐述DDD的价值、方法和架构,欢迎任何的问题指正和补充。 DDD过程 领域驱动设计是一套面对复杂业务进行建模和设计的方法论和实践,建立了以领域为核心驱动力的设计体系。领域驱动设计分为2个主要过程:战略设计、战术设计。 ? DDD驱动我们把每一个限界上下文设计成一个个“自治”的单元,自治要满足四个特点: ? 领域驱动设计给出了DDD分层架构、六边形架构、整洁架构等分层架构,它们遵循“关注点分离”原则,旨在分离和隔离业务复杂度和技术复杂度,凸显了领域模型,保证了领域模型的稳定性和一致性。 2.2.2.6、领域事件(Repository) 在Eric的《领域驱动设计》中并没有提到领域事件,领域事件是最近几年才加入DDD生态系统的。

    2K00发布于 2020-03-16
  • 来自专栏程序员的SOD蜜

    领域驱动设计(DDD)技术分享

    4       DDD--领域驱动设计: 4.1     领域模型 DDD,着重强调:-领域模型 PS:以我们这次项目为原型做好的领域模型介绍。 4.2     DDD实践的关键步骤: 4.2.1  领域建模 UML是一种建模工具,画草图,文档,讨论组等。。。。 UML强调的主要功能是“沟通”,把UML工具作为沟通的重要工具。 ,在DDD中,是Domain Layer需要什麽,Repository Layer提供什麽;而在DAL中相反,不管BLL是否需要,先提供一堆DAL方法再说,没有“领域”的需求。 4.4     领域驱动开发模式的开发过程 1、分析业务需求。 6       附录 6.1     参考资源: UML类图关系大全 http://www.cnblogs.com/riky/archive/2007/04/07/704298.html “领域驱动开发

    1.8K90发布于 2018-02-27
  • 来自专栏芋道源码1024

    领域驱动设计(DDD):领域接口化设计

    来源:juejin.cn/post/6894109393173315597 领域接口化设计 领域接口化 关联接口化 系统接口化 开源电商 总结 ? ---- 领域接口化设计 把服务对象(service)和资源库对象(repository)设计成接口是最常见的。 所以我们要讨论的是全面接口化,尤其是对领域模型 接口化的认识。 领域接口化 通常的情况下我们会把领域模型设计成类(class) ,但是你有没有想过把领域模型设计成接口(interface) ? 具体来说是在持久层使用持久化对象(PO)与领域对象(DO)的之间进行转换。 领域模型采用领域驱动设计(DDD)、接口化以及面向对象设计。

    1.3K10发布于 2021-08-09
  • 来自专栏JavaEdge

    DDD领域驱动设计实战(六)-领域服务

    领域中的服务表示一个无状态的操作,它用于实现特定于某个领域的任务。 当某个操作不适合放在聚合和值对象上时,最好的方式便是使用领域服务。 有时我们倾向于使用聚合根上的静态方法来实现这些这些操作,但是在 DDD中,这是一种坏味道 本文目标 如何在领域模型中使用领域服务 什么是领域服务 何时应该使用领域服务 从案例学习如何对领域服务进行建模 以上这些都不是领域服务。 请不要将领域服务与应用服务混淆。 应用服务并不会处理业务逻辑,但领域服务恰恰是处理业务逻辑。应用服务是领域模型很自然的客户,也是领域服务的客户。 通常领域模型主要关注特定于某个领域的业务。同样,领域服务也具有相似特点。由于领域服务有可能在单个原子操作中处理多个领域对象,这将增加领域服务的复杂性。 即便如此,DDD仍然有强烈的理由不这么做。当然,选择权在你自己手上。 有时,领域服务总是和领域密切相关,并且不会有技术性的实现,或者不会有多个实现,此时采用独立接口便只是一个风格上的问题。

    2.3K00发布于 2021-02-23
  • 来自专栏JAVA乐园

    如何理解领域驱动设计 DDD

    本文章的中奖名单《数据库排名:MySQL跳出“同期跌幅榜”,拿下“涨幅榜冠军”》 文末公布 DDD领域驱动设计)是软件开发中的一个非常重要的设计方式,它被誉为面向对象开发的正确使用方式。 你也许会疑惑,领域驱动设计这么简单?对的,它就是这么简单。 DDD同时又是一个非常容易被误解的概念,同时网上90%的领域模型教程、领域驱动设计方式文章都是错误的打开方式,它们会使得这个概念更加让人摸不着头脑。 DDD教程很多会说到贫血模型、充血模型、建立领域知识、和领域专家深入交流啥啥啥的,这些统统不用管。下面我将详细说说DDD如何学,如何用。 0x02:DDD如何学 然后我说说领域驱动如何学。 模块划分完成后,按照使用者的思维方式来设计接口,比如用户模块有注册接口、登录接口、图书模块有查询借阅等等接口等等……,这样就完成了非常出色的DDD领域驱动设计。

    1K30发布于 2021-03-22
  • 来自专栏dowhatyoulove

    领域驱动设计(DDD): why what how

    屏幕快照 2020-02-24 上午3.35.28.png 屏幕快照 2020-02-24 上午3.35.44.png 屏幕快照 2020-02-24 上午3.35.52.png 屏幕快照 2020-02-24 上午3.36.01.png 屏幕快照 2020-02-24 上午3.36.08.png 屏幕快照 2020-02-24 上午3.36.15.png 屏幕快照 2020-02-24 上午3.36.23.png 屏幕快照 2020-02-24 上午3.36.29.png 屏幕快照 20

    53200发布于 2020-02-28
  • 来自专栏JavaEdge

    DDD领域驱动设计-充血模型、贫血领域模型

    作为领域模型的推广者,他们觉得这不是一件好事。 贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。 贫血领域模型的根本问题在于,它引入了领域模型设计的所有成本,却没有带来任何好处。 最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。 将行为放入领域模型,这点和分层设计(领域层、持久化层、展现层等)并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。 但是,这并不意味着领域模型就不应该包含行为。事实上,service层需要和一组富含行为的领域模型结合使用。 参考 《领域驱动设计》 https://www.zhihu.com/question/20360521/answer/14891150 https://www.martinfowler.com/bliki

    1.1K30发布于 2021-02-23
领券