- 综合排序
- 最热优先
- 最新优先
- 来自专栏Java技术圈子
DDD领域驱动设计初探
欢迎批评指正 DDD 强调领域模型要兼顾业务和技术两个视角。 我们怎么用一套系统化的方法，抽丝剥茧、一步一步地把需求落实到代码呢？咱们看看下面这张图，它表示了领域驱动设计中的主要流程。 1 领域驱动设计主要的开发流程你可以看到，在整个开发流程中，首先是要捕获行为需求，也就是传统软件工程里的“获取需求”。 DDD 的领域模型，大体上相当于传统软件工程中的分析模型。 基于领域模型，我们就可以做架构设计，包括进程间和进程内的架构。比如说微服务设计、中台设计都属于进程间架构。 而 DDD 分层架构，通常说的是进程内架构。 然后就可以根据领域模型进行数据库设计，最后是代码实现。 这样，就形成了一个基于 DDD 的开发闭环。 数据库建表 DDD 主张要根据领域模型来进行数据库设计，保证数据库和领域模型的一致，从而保证数据库和业务需求以及代码的一致性。
70120编辑于 2023-04-10 - 来自专栏_春华秋实
了解 DDD 领域驱动设计
常见的编程范式包括面向对象编程、函数式编程、命令式编程等 DDD（领域驱动设计，Domain-Driven Design）应用架构：一种软件开发方法论，强调以业务领域模型为核心，通过领域模型紧密协作来构建复杂系统的架构 DDD 架构和三层应用架构对比 核心代码位置的不同 在 DDD (领域驱动设计) 中，需要将重点放在领域层（Domain Layer）进行业务逻辑和规则的实现。 三层架构中业务逻辑都堆积在 Service 层 编程范式的不同 领域驱动中使用了面向对象和 命令式编程两种方式 通过面向对象抽象领域模型 通过命令式编程，编排业务逻辑 三层架构中使用过程式编程（命令式编程 参考链接和推荐阅读 Go 的 DDD 工程化项目实践 简化代码模块设计：两种高效编程范式 八年实战经验，解读DDD思想内核 第一件事，它提供了一种给“应用层”或“服务层”分类的方法。 现在再来看这张DDD的典型架构图，你可能会更加理解DDD的思想内核，这是一种面向领域的设计方法，把领域层（业务规则）包在最里面，保护好边界，避免领域层被污染。
38720编辑于 2025-01-22 - 来自专栏若尘的技术专栏
领域驱动设计（DDD）实践
不能说微服务拯救了领域驱动设计，但确实是微服务，让领域驱动设计又重新焕发了青春。 因此在战略设计阶段，微服务扩展了领域驱动设计的内容，反过来领域驱动设计又能够保证良好的微服务设计。 边界给了实现限界上下文内部的最大自由度。 DDD 过程 领域驱动设计是一套面对复杂业务进行建模和设计的方法论和实践，建立了以领域为核心驱动力的设计体系。领域驱动设计分为 2 个主要过程：战略设计、战术设计 。 领域驱动设计给出了 DDD分层架构、六边形架构、整洁架构等分层架构，它们遵循“关注点分离”原则，旨在分离和隔离业务复杂度和技术复杂度，凸显了领域模型，保证了领域模型的稳定性和一致性。 领域事件（Repository） 在 Eric 的《领域驱动设计》中并没有提到领域事件，领域事件是最近几年才加入 DDD生态系统的。
1.1K84发布于 2021-11-23 - 来自专栏技术那些事
DDD领域驱动设计实践
领域驱动设计分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；由领域模型驱动软件设计，用代码来实现该领域模型 ； 由此可见，领域驱动设计的核心是建立正确的领域模型。 领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。 领域建模是领域专家、设计人员、开发人员之间沟通交流的过程，是大家工作和思考问题的基础。 从经典的领域驱动设计分层架构中可以看出，领域层的上层是应用层，下层是基础设施层。 比如命令部分可以通过领域驱动设计来实现；查询部分可以直接用最快的非面向对象的方式去实现，比如用SQL。
95050发布于 2021-04-02 - 来自专栏架构之家
领域驱动设计（DDD）：领域接口化设计
所以我们要讨论的是全面接口化，尤其是对领域模型接口化的认识。 领域接口化 通常的情况下我们会把领域模型设计成类（class），但是你有没有想过把领域模型设计成接口（interface）？ 最开始要把领域对象设计成接口，确实是为了在不同的 ORM 框架之间实现无缝切换。因为 JPA 对面向对象的支持最好，而 Mybatis 因为简单在大环境下比较流行。 如果我们把领域对象设计成接口类型，并与服务接口以及其它接口一起组织在一个新的模块内，形成一个新的接口（API）模块。 领域模型采用领域驱动设计（DDD）、接口化以及面向对象设计。 总结 领域对象接口化使得我们在内部实现了一套统一的接口，并将领域对象接口化扩展到系统级别时，我们又在系统层次上设计出一套统一地全局接口来开发业务和应对未来变化的环境。
95410编辑于 2022-07-12 - 来自专栏分母为零
DDD-领域驱动设计
DDD-领域驱动设计 参考DDD的设计，DDD官方的架构草图，总体架构分为四层，Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces 在领域驱动设计中根据重要性与功能属性将领域分为三类子域，分别是：核心子域、支撑子域和通用子域。决定产品和企业独特竞争力的子域是核心子域，它是业务成功的主要因素和企业的核心竞争力。 首先确定核心域,确定完核心子域后，根据对这个领域的理解划分出各个上下文，然后根据上下文再确定其他的相关领域。 用DDD走出设计微服务拆分困境 所谓的微服务拆分困难，其实根本原因是不知道边界在什么地方。 而使用DDD对业务分析的时候，首先会使用聚合这个概念把关联性强的业务概念划分在一个边界下，并限定聚合和聚合之间只能通过聚合根来访问，这是第一层边界。
1.3K10发布于 2019-08-13 - 来自专栏琦小虾的Binary
领域驱动设计 (DDD) 总结
DDD 简述 DDD (Domain-Driven Design)，即领域驱动设计是思考问题的方法论，用于对实际问题建模，它以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，然后将这些概念设计成一个领域模型 由领域模型驱动软件设计，用代码来实现该领域模型。所以，DDD 的核心是建立正确的领域模型。 二. 领域驱动设计的模式 ? 4.1 关联的设计 关联本身不是一个模式，但它在领域建模的过程中非常重要，所以需要在探讨各种模式之前，先讨论一下对象之间的关联该如何设计。 /pic/DDD经典分层结构.png)] 上图为经典的领域驱动设计分层架构，图中领域层 (Domain) 的上层是应用层 (Application)，下层是基础设施层 (Infrastructure)， 上下文图 (Context Map) 参考地址：《【DDD】领域驱动设计实践 —— 限界上下文识别》 9.1 上下文图类型 多个系统之间会发生关系，存在交互，这也必然会在各自的限界上下文有所表现。
3.7K51发布于 2020-07-15 - 来自专栏芋道源码1024
领域驱动设计（DDD）：领域接口化设计
来源：juejin.cn/post/6894109393173315597 领域接口化设计 领域接口化 关联接口化 系统接口化 开源电商 总结 ? ---- 领域接口化设计 把服务对象（service）和资源库对象（repository）设计成接口是最常见的。 领域接口化 通常的情况下我们会把领域模型设计成类（class） ，但是你有没有想过把领域模型设计成接口（interface） ？ 领域模型采用领域驱动设计（DDD）、接口化以及面向对象设计。 ，并将领域对象接口化扩展到系统级别时，我们又在系统层次上设计出一套统一地全局接口来开发业务和应对未来变化的环境。
1.3K10发布于 2021-08-09 - 来自专栏爬蜥的学习之旅
领域驱动设计(DDD)概念入门
领域设计中战略设计 通用语言：用一种语言来清晰的阐述从领域专家的讨论到代码的各个问题和他们的解决方式，但是问题有许多，每一种问题都有各自的通用语言，因此希望在软件的实现上，通过一个边界来使得边界内仅有一种语言 开放主机/消息：定义一种协议，方便不同限界之间通信 防腐层：不同模型之间进行转义 防腐层的作用可以通过如下视图来感受，当你从外面进入房子内部的时候，有一个换鞋的地方，这个地方就可以看做是防腐层 领域设计中的战术实现 只为确实需要直接访问的聚合提供资源库，让客户能聚焦于模型 分层模型中使用领域驱动设计 领域驱动设计不需要使用特定的架构，它可以应用于多种架构中，以分层模型为例，一个应用程序可以分成： 用户界面层：处理用户显示和用户请求 从而使得状态变更与决策放在展示层，与视图分开，比如某个组件是否可编辑可用true表示可以编辑，而false不可编辑，但是true/false的取值却是有展现层进行赋值 参考 Eric Evans演讲what is DDD Eric Evans演讲bounded context Eric Evans 书 <领域驱动设计-软件核心复杂性应对之道> Vaughn Vernon 书 <实现领域驱动设计> Martin Fowler
1K20编辑于 2022-03-09 - 来自专栏用户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驱动我们把每一个限界上下文设计成一个个“自治”的单元，自治要满足四个特点： ? 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 领域驱动开发模式的开发过程 １、分析业务需求。 ２、设计领域对象模型 ３、测试领域对象模型 ４、设计业务处理类 ５、设计Entity和ViewModel ６、测试业务处理类 ７、设计表架构 ８、开发用户界面 5 数据库查询最有损效率的地方
1.8K90发布于 2018-02-27 - 来自专栏小强的进阶之路
领域驱动设计（DDD）：领域和子域
实现业务其实是在实现所在业务领域 中所需要的业务。技术也是一个领域，称之为技术领域 。领域驱动设计中的领域 是指的业务领域。 domain-words 百度百科对领域 的解释： 学术思想或社会活动的范围。 具体指一种特定的范围或区域。 《领域驱动设计》中领域指的是一个特定的业务范围 ，大家在这个业务域范围内开展工作。 subdomains 这是一个有关“零售商在线销售产品”的例子，来源于《实现领域驱动设计》。 把零售商中的所有业务看做成一个领域（业务域） ，把这个整体业务域中的每一个业务域看做成子域 。 有关核心域的更多内容请阅读《领域驱动设计》中的第十五章，其中非常详细地阐述了如何明确核心域和实现核心域。 《实现领域驱动设计》中通过问题空间 和解决方案空间 对核心域做了更直接的说明： 问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。
1.7K40发布于 2021-04-14 - 来自专栏JAVA乐园
如何理解领域驱动设计 DDD
本文章的中奖名单《数据库排名：MySQL跳出“同期跌幅榜”，拿下“涨幅榜冠军”》 文末公布 DDD（领域驱动设计）是软件开发中的一个非常重要的设计方式，它被誉为面向对象开发的正确使用方式。 你也许会疑惑，领域驱动设计这么简单？对的，它就是这么简单。 DDD同时又是一个非常容易被误解的概念，同时网上90%的领域模型教程、领域驱动设计方式文章都是错误的打开方式，它们会使得这个概念更加让人摸不着头脑。 DDD教程很多会说到贫血模型、充血模型、建立领域知识、和领域专家深入交流啥啥啥的，这些统统不用管。下面我将详细说说DDD如何学，如何用。 0x02：DDD如何学 然后我说说领域驱动如何学。 模块划分完成后，按照使用者的思维方式来设计接口，比如用户模块有注册接口、登录接口、图书模块有查询借阅等等接口等等……，这样就完成了非常出色的DDD领域驱动设计。
1K30发布于 2021-03-22 - 来自专栏慕枫技术笔记
DDD领域驱动设计落地实践系列：初识DDD
引言 笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计，尤其是在业务梳理、中台规划以及微服务划分等方面，DDD是重要的架构设计方法论，对平时的架构设计有非常好的指导作用。 DDD领域驱动设计：我们接触的系统越来越庞大了，涉及的子系统也越来越多了，传统的软件设计方式已经不能满足我们应对复杂系统的设计。 而DDD提供了我们应对大型复杂系统的领域建模以及分析的方法论。 第一种方式咱们就不说了，我们可以来看下数据驱动和DDD领域驱动设计。其实这两种设计方式最大的不同就是设计思想的转变。 而DDD关注领域模型，通过领域模型驱动整个系统的软件设计，让那个领域模型与数据模型解耦，明确业务边界，从而能够更好的指导我们完成复杂系统的架构设计。 DDD 上文中通过不同软件设计方式的描述，引出了DDD领域驱动设计模式，那么我们就来看下DDD到底是什么。所谓DDD即Domain Driven Design，字面意思就是领域驱动设计。
95330编辑于 2023-03-20 - 来自专栏JavaEdge
DDD领域驱动设计实战(六)-领域服务
有时我们倾向于使用聚合根上的静态方法来实现这些这些操作，但是在 DDD中,这是一种坏味道 本文目标 如何在领域模型中使用领域服务 什么是领域服务 何时应该使用领域服务 从案例学习如何对领域服务进行建模 当时这种设计方式非常完美，businessPriorityTotals只需遍历所有 Backlogitem实例，计算出总业务优先级。 = null) { authentic = user.isAuthentic(aPassword); } return authentic; 以上设计至少存在如下问题 客户端需要知道某些认证细节 但还有人认为将接口和实现类放在相同包中会使包变很大，这是一种糟糕的模块设计，因此他们偏向于将接口和实现类放在不同包，我们在依赖倒置原则便是这么做。 即便如此，DDD仍然有强烈的理由不这么做。当然，选择权在你自己手上。 有时，领域服务总是和领域密切相关，并且不会有技术性的实现，或者不会有多个实现，此时采用独立接口便只是一个风格上的问题。
2.3K00发布于 2021-02-23 - 来自专栏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 - 来自专栏从入门到出门
领域驱动设计DDD核心思想
领域驱动设计DDDDomain-Driven DesignDDD设计完成之后，才能划分微服务，不然无法确定每一个微服务里头都包含哪一些功能。 限界上下文包括：输入适配器，例如用户界面；编排用例和管理事务的应用服务；领域模型；输出适配器，如持久化管理和消息发送器；3.战略设计之子域理想情况下，一个限界上下文对应一个子域，子域是整个业务领域的一部分 子域类型核心域支撑子域（定制开发）通用子域4.战略设计之上下文映射核心域必须与其他限界上下文进行集成。这种集成关系在DDD中称为上下文映射。 聚合要设计的小巧。只能通过标识符引用其他聚合。使用最终一致性更新其他聚合。6.战术设计之运用领域事件通过消息机制来实现领域事件，要保证事件的顺序性，同时要可以事件溯源。 7.加速和管理工具事件风暴事件风暴是一种快速的设计技术，让领域专家和开发人员都可以参与到这个快节奏的 学习过程中 它聚焦于业务和业务流程，而非名词概念和数据运用SWOT分析法建模Spike 和建模债务任务识别与工作量估算限制建模时间
1.1K30编辑于 2022-08-01 - 来自专栏憧憬博客分享
DDD领域驱动设计的概念解析
DDD领域驱动设计的概念解析 在学习 DDD领域驱动设计 的过程中，这种方法包括特别的抽象概念，晦涩难懂，本文结合作者理解，对其方法论中的一些概念进行解析。 ，可以理解 DDD 这个方法论，帮我们对业务、类等的相同的特征进行了抽象、找出公共特征进行归类，利用分治思想帮助架构设计，从而保证了模块之间的高内聚和低耦合。 从而进行领域建模，简而言之就是对需求进行建模，然后利用 DDD 的概念进行划分 领域事件 领域事件用来表示领域中发生的事件。 DDD提倡从领域模型设计出发，而不是先设计数据模型。实体和值对象是微服务底层的最基础的对象，一起实现实体最基本的核心领域逻辑。 聚合在 DDD 中属于领域层，领域层包含多个聚合，共同实现核心业务逻辑。跨多个实体的业务逻辑通过领域服务实现，跨多个聚合服务通过应用服务来实现。
1.5K21发布于 2021-06-02 - 来自专栏架构精进之路
领域驱动设计（DDD）靠谱么？
DDD分层架构 相信大部分了解DDD的开发者，持支持的观点主要认为： DDD（Domain Driven Design，领域驱动设计）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。 在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。 Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式。 这一层主要包括 Facade、DTO还有一些Assembler； 应用层 Application：这一层包含的主要组件就是 Service 服务，但是要特别注意，这一层的Service不是简单的DAO层的包装，在领域驱动设计的架构里面 使用 DDD 指导微服务划分，能在一定程度上弥补经验的不足，做出有理有据的系统架构设计。 做个总结吧 领域驱动开发的关注点在于领域模型，所有的考虑都应该从领域的角度出发，重心放在业务。
99710编辑于 2022-05-06
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号