- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构之家
领域驱动设计（DDD）：领域接口化设计
所以我们要讨论的是全面接口化，尤其是对领域模型接口化的认识。 领域接口化 通常的情况下我们会把领域模型设计成类（class），但是你有没有想过把领域模型设计成接口（interface）？ 最开始要把领域对象设计成接口，确实是为了在不同的 ORM 框架之间实现无缝切换。因为 JPA 对面向对象的支持最好，而 Mybatis 因为简单在大环境下比较流行。 如果我们把领域对象设计成接口类型，并与服务接口以及其它接口一起组织在一个新的模块内，形成一个新的接口（API）模块。 领域模型采用领域驱动设计（DDD）、接口化以及面向对象设计。 总结 领域对象接口化使得我们在内部实现了一套统一的接口，并将领域对象接口化扩展到系统级别时，我们又在系统层次上设计出一套统一地全局接口来开发业务和应对未来变化的环境。
95410编辑于 2022-07-12 - 来自专栏超级架构师
【领域驱动设计】Redux 和领域驱动设计
Redux 的创建者 Dan Abramov 说他不知道什么是领域驱动设计。尽管如此，令人印象深刻的是 Redux 与 DDD 的相似之处。 理解两者，我们可以提供更好的实现；来自不同世界的两种方法相互碰撞并利用相同的设计原则。 领域驱动设计 领域驱动设计是一种软件建模技术，旨在创建强大的微服务架构以及集成多个现有解决方案。 Eric Evans 最初于 2003 年在《领域驱动设计：解决软件核心中的复杂性》一书中提出它。目前，DDD 有更多的书籍、更多的示例，并且已被证明可以有效地扩展和保持大型系统中的高级性能。 他们消费领域事件以保持其状态一致，同时，他们为每个突变生成新的领域事件。聚合示例：post。 不幸的是，许多人混淆了命令和领域事件。两者都是动词，都可能暗示状态的变化，但它们是不同的。 Redux Redux 与领域驱动设计有着惊人的关联。虽然它不共享相同的术语，但想法是存在的。Redux 几乎是功能范式中 DDD 策略的实现。
1.9K30编辑于 2022-05-11 - 来自专栏芋道源码1024
领域驱动设计（DDD）：领域接口化设计
来源：juejin.cn/post/6894109393173315597 领域接口化设计 领域接口化 关联接口化 系统接口化 开源电商 总结 ? ---- 领域接口化设计 把服务对象（service）和资源库对象（repository）设计成接口是最常见的。 领域接口化 通常的情况下我们会把领域模型设计成类（class） ，但是你有没有想过把领域模型设计成接口（interface） ？ 领域模型采用领域驱动设计（DDD）、接口化以及面向对象设计。 ，并将领域对象接口化扩展到系统级别时，我们又在系统层次上设计出一套统一地全局接口来开发业务和应对未来变化的环境。
1.3K10发布于 2021-08-09 - 来自专栏程序员升级之路
领域驱动设计——柔性设计
一、什么是柔性设计 这个概念来自《领域驱动设计——软件核心复杂性应对之道》一书： 为了使项目能够随着开发工作的进行加速前进，而不会由于它自己的老化停滞不前，设计必须要让人们乐于使用，而且易于修改。 《领域驱动设计——软件核心复杂性应对之道》 说简单点，指的是系统保持良好的扩展性，当有新需求时，旧的系统需要能容易、方便、高效的修改，以达到快速交付。 二、如何进行柔性设计 书中讲了几个模式： 1、INTENTION-REVEALING INTERFACES（意图提示接口） 网上有不同的中文翻译，这里翻译的可能不太准确，所以把原文说出来了。 如果开发的同学为了使用一个类或一个方法必须研究它的实现，那封装就失去了价值，进而设计的概念基础已经被误用了，所以可能被误用。 确保导致状态改变的方法不返回领域数据，并尽可能保持简单。 4）、实在有复杂的逻辑，主要针对可能产生副使用的，尽量放到Value Object中（DDD相关概念，这里不详述）。
1.7K30发布于 2021-05-11 领域驱动设计
本文对《领域驱动设计-软件复杂性应对之道》一书进行高度凝练，梳理了领域驱动设计的架构图、基本要素和重要概念。从细节入手，以小见大，你想知道的定义，这里都有。 指导做架构设计？说对了一半，没讲到精髓。先来看一张架构图示例：这是现在很典型的一种架构分层，横向先根据不同技术领域先分几层，大差不差也不会有什么人挑战。 一、构造块构造块是指领域设计中最基本的一些元素。构造块大图 1.1 分层架构 应用层和领域层的关系接收订单：顾客向前台经理（应用服务层）点单。前台经理验证订单的有效性。 领域层处理具体的业务逻辑，返回结果给应用服务层分层是常用的方法，不仅是领域驱动设计，计算机网络也会看到分层思想：网络的七层模型。分层的好处在于：可以集中精力关注每一层的功能职责，更好地分工协作。 聚合根示意图 1.7 factory 工厂 factory 负责复杂对象和aggreate的创建，是领域设计的一部分。
46901编辑于 2025-01-18- 来自专栏ThoughtWorks
《领域驱动设计》
一、领域驱动设计为何又焕发青春？ 领域驱动设计（Domain Driven Design，DDD）确实已不再青春，从 Eric Evans 出版了划时代的著作《领域驱动设计》至今，已有将近十五年的时间，在软件设计领域中，似乎可以称得上是步入老年时代了 直到行业内吹起微服务的热风，人们似乎才重新发现了领域驱动设计的价值，并不是微服务拯救了领域驱动设计，是因为领域驱动设计一直在坚硬的生长，然而看起来，确乎因为微服务，领域驱动设计才又焕发了青春。 学习领域驱动设计可能会给你带来的收获： 领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。 领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。
73430发布于 2018-08-03 - 来自专栏程序猿DD
领域驱动设计
关于领域驱动设计 这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》，二者详细描述了领域驱动设计的核心概念、技术和模式。 值得注意的是，DDD还鼓励将其他领域的概念收入囊中，比如测试驱动开发，设计模式的使用，以及持续重构。 代表模型 领域驱动设计的最主要目的是为了设计和创造出富有表达力的模型。 这些术语不会增加价值，但是它们是深入挖掘领域驱动设计的极好线索。 用户有一个状态 状态可能是一个标志或者字段。也许领域专家对其他系统如电子表格很熟悉，并建议使用同样的实现。 HOT TIP:记住聚合的两个作用:简化领域设计和改进技术。 应用架构 当设计的重点在于创建行为丰富的领域模型时，那么相应的架构设计必须保证模型不受基础设施的影响。通常来说，分层架构可以将领域与系统中的其他层分隔开，并且每一层只能感知它下一层的存在。
1.2K90发布于 2018-03-21 - 来自专栏全栈程序员必看
实现领域驱动设计pdf_领域驱动设计实例
在上一部分，分层架构的目的是为了将业务规则剥离出来在单独的领域层中进行实现。再回顾一下领域驱动设计的分层中应用层代码的实现。 领域对象的持久化交给了基础设施层，这里，Repository目的是持久化领域对象状态。 领域驱动设计，即领域模型驱动程序设计，它的核心是保证系统的实现与实际的业务规则一致，完整实现了领域模型。 它包含了两个部分：领域模型、领域模型的编程实现。 在软件设计和实现过程中要充分利用领域模型，设计过程中，领域模型作为与业务专家的沟通语言；实现过程中，领域模型作为与开发人员沟通的语言。 ===================== 领域知识：装修设计预约平台 1 客户通过系统预约设计师进行装修设计，客户只能预约一个设计师订单，不能预约多个同时进行设计。 ，但它仍是领域设计的一部分。
2.1K20编辑于 2022-09-20 - 来自专栏一起玩转.NET
如何运用领域驱动设计 - 领域服务
概述 本文将介绍领域驱动设计（DDD）战术模式中另一个非常重要的概念 - 领域服务。在前面两篇博文中，我们已经学习到了什么是值对象和实体，并且能够比较清晰的定位它们自身的行为。 此时，你可能需要一个领域服务来完成操作。 那么，到底什么是领域服务呢？怎么发现领域中的领域服务呢？领域服务和传统的应用服务又有什么区别呢？ 看看原著原著《领域驱动设计:软件核心复杂性应对之道》中所提及到的领域服务的概念： 在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上讲不属于任何对象。 来回顾一下上面所说的概念：“在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上讲不属于任何对象。” 仔细读几遍，纳尼？这不是说的就是这个情况吗？ 那么，你也许用错了领域服务，去重新认识你所识别出的实体和值对象，为它们赋予他们自身的行为，删除这些错误的领域服务。 总结 本次我们介绍了领域驱动设计战术模式中的领域服务。
99730发布于 2020-04-27 - 来自专栏dotNET知音
如何运用领域驱动设计 - 领域事件
概述 在实践领域驱动设计（DDD）的过程中，我们往往会遇到多个领域对象相互交互的情况。比如聚合根A在执行某操作之前需要得到聚合根B的某个信号（或某些数据）。 什么是领域事件 在原著 《领域驱动设计:软件核心复杂性应对之道》 其实并没有直接提及到关于领域事件的介绍。 此处我摘录了《实现领域驱动设计》书中对领域事件的描述： 领域专家所关心的发生在领域中的一些事件。 将领域中所发生的活动建模成一系列的离散事件。 这就是领域事件设计模式所带来的价值。” 所以在大多数时候您将感受到项目逐渐具有 EDA（事件驱动架构）的风格。 总结 本次我们介绍了领域驱动设计中的领域事件。“如果捕获领域事件？”，“DDD是否一定需要领域事件？”相信这些问题，看到这里您心里已经有了自己的答案。
89610发布于 2020-03-18 - 来自专栏领域驱动设计DDD实战进阶
领域驱动设计之关联设计
在找到实体与值对象后，我们就需要进行对象之间的关联设计。 1.关联尽量少，不要形成复杂的关系网。
1.4K40发布于 2018-05-11 - 来自专栏IT专栏
领域驱动设计之我见
它为我们提供了设计软件的一个全新视角，同时也给开发者留下了一大难题：如何将领域驱动设计付诸实践？ 分层架构的落地就简单明了了，用户界面层我们可以理解成web层的Controller，应用层和业务无关，它负责协调领域层进行工作，领域层是领域驱动设计的业务核心，包含领域模型和领域服务，领域层的重点放在如何表达领域模型上 而在领域层内部，所有的概念（字段名），所有的领域对象，将是含义明确的、统一的。 拙劣的设计各有不同，优秀的设计大同小异！！！ 推荐书目： 《领域驱动设计 软件核心复杂性应对之道》 《实现领域驱动设计》 《领域驱动设计模式、原理与实践》 《分析模式——可复用的对象模型》 参考： 领域驱动设计，盒马技术团队这么做 领域驱动架构篇 菱形对称架构 领域驱动设计DDD和CQRS落地
75220发布于 2021-11-22 - 来自专栏斑斓
领域驱动设计揭秘
我在2020年领域驱动设计中国峰会的分享，主题为：领域驱动设计揭秘。分为四个部分： 领域驱动设计 vs. 数据驱动设计 领域驱动设计的黑铁时代和黄金时代 单体架构是邪恶的吗 领域驱动设计的不足与领域驱动设计统一过程 ¶ 领域驱动设计 vs. 数据驱动设计 通过比较领域驱动设计和数据驱动设计，探讨为何基于数据库进行设计容易催生出贫血模型与事务脚本，指出领域驱动设计与数据驱动设计的不同之处在于限界上下文和聚合。 ¶ 领域驱动设计的不足与领域驱动设计统一过程 我承认领域驱动设计无论伦比的设计魅力，尊敬Eric Evans卓越的洞见与设计前瞻能力，但也不讳言领域驱动设计本身存在的不足。 这几年，领域驱动设计随着微服务的流行变成了显学，但领域驱动设计不是“银弹”，既然如此，领域驱动设计统一过程（DDD-UP）就更不是“银弹”了，它不过是对领域驱动设计的一种补充和完善罢了。
53220编辑于 2023-03-23 - 来自专栏程序员宇说
我的领域驱动设计运用实例 - 领域啊领域
本篇文章是开篇，因为领域驱动设计相关的知识真的不怎么好懂，如果行文中出现错误的地方，欢迎大家在评论区指出，先行感谢。 第一篇介绍的是我认为领域驱动设计中一个最基础的东西，也是很多文章中并没有说的，如何去识别出业务领域并进行划分。 2、领域划分 领域驱动设计，在维基百科中对于领域的解释如下，因为词条的中文解释应该是机翻的，所以这里放出英文原文，下方的中文是我基于个人理解所提供的翻译，仅供参考。 因此，领域驱动设计中的领域就是这个业务边界范围内想要解决的业务问题域。 一个业务领域可以继续划分，最终实现将业务域进行不断的拆解，从而降低对于整体业务的理解和系统实现的复杂度； 四、参考资料 阿里盒马领域驱动设计实践 DDD理论学习系列——案例及目录 浅谈我对DDD领域驱动设计的理解
88610发布于 2020-02-18 - 来自专栏JusterZhu
浅析领域驱动设计
1.概要 DDD（Domain-driven design，模型驱动设计）是一种软件设计的指导思想，而非固定的一套公式化开发模板（这样就会导致网络上出现各种基于自己或业务上的理解而产出的DDD落地的实现 任何技术或者设计都需要整体的评估，而不是一味地去迎合。 接下来让我们看看什么是领域驱动设计。 1.1需求分析 需求分析的方式有很多，例如：用例法，四色建模法。 关心的业务重点不同，领域的划分也不同。 项目初期应考虑的是如何领域建模，用业务语言去描述和构建系统。而不是用技术语言，去思考代码怎么写。技术是服务于业务的脱离业务谈技术或者架构、设计都是空谈。 所以在做领域设计的时候大家一定要想清楚当时定义的意思和作用。 因为在做的时候我们的领域是不需要数据的，只要测试通过表示系统的关键业务没有出问题。 性能测试：根据在设计系统的时候，需要设置指标比如系统支撑的最大上限是多少，检测是否满足性能指标。
1K10编辑于 2023-01-10 - 来自专栏微观技术
聊聊领域驱动设计
当然随着你在一个领域摸爬滚打时间越长，在这个领域中积累的技术经验会越来越丰富。 设计：主要指领域模型的设计，领域模型是整个系统的核心。 每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题 驱动：是以领域为边界，分析领域中的核心问题（核心关注点），然后设计对应的领域模型，再通过领域模型驱动代码实现。 •设计时应考虑一定的抽象性、通用性，以及复用价值；•模型持续重构、完善、优化； 设计思路 1、理解领域 明确要设计一个什么样的系统，要解决什么核心问题。 4、领域模型设计 DDD提供很多实用的建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。我们可以使用这些工具，来设计每一个子域的领域模型，最后产出领域模型图。 下图是电商系统的商品中心的领域模型图： ? 5、技术要素 框架选型、架构设计、容量规划、数据库设计、分库分表方案、缓存设计、高并发解决方案、监控报警等 架构设计 微服务 • 强模块化边界。
1K10发布于 2020-08-20 - 来自专栏IT技术订阅
领域驱动设计-下
DDD架构 传统分层架构 分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。 开发设计时，不要将本该放在领域层的业务逻辑放到应用层。因为庞大的应用层会使领域模型失焦，时间一长微服务就会演化为传统MVC三层架构，导致业务逻辑混乱。 DDD架构和MVC架构 MVC架构，目前典型实现包括SpringMVC,Spring Boot，固化业务，是一种结构性设计模式，也是一种面向数据的设计。 ，即只针对核心关注点，而不是整个领域中的所有问题； 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值； 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题； 领域模型是系统的核心 ，是领域内的业务的直接沉淀，具有非常大的业务价值； 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地； DDD架构作为一套先进的方法论，在很多场景能发挥很大价值，高级的架构师把DDD架构当成一种工具
1.1K30编辑于 2022-06-23 - 来自专栏Wooola的技术博客
领域模型设计实战
二、领域模型设计 在分析出本次方案的领域模型后，我们继续进行下一步工作领域模型设计。 在上一阶段的分析过程中，我们已经明确了本次的核心服务是计费和计税。我们先基于计费进行相关的设计工作。 通过领域服务设计，再回过头去分析领域服务和对应领域对象的关系，我们可以分析出以下几点： 1、 通话相关的模型属于应用模型，不属于系统的领域对象，计费对应不局限于通话。 缺少域的划分，各个领域模型的职责边界不能很好的描述清楚。 第三组 领域模型设计可以满足本次需求，能够处理计费和计税问题。 基于本次需求可以满足，针对后续业务的扩展设计有所不足。 针对领域建模知识的感悟： 4、 领域模型设计,不是直接的系统设计.需要清楚了解概念之间的差异。 5、 领域模型不是表的关系图,是对业务的高度抽象,将业务中的实体抽象出来,帮助我们理解和分析业务。 6、 模型设计要考虑清楚边界划分,模型归属的域范围,不要将不同范围的属性耦合到一个模型里。 7、 一个好的领域模式设计是可以指导后续详细分析展开以及编码的。
97230发布于 2021-07-07 - 来自专栏ThoughtWorks
再谈领域驱动设计
本文从需求分析到API设计，试图描述领域驱动设计的过程及思想。同时也能看的出领域驱动设计并不是孤立存在的，它为解决开发团队和业务人员之间沟通而生，进而驱动微服务的划分以及API的设计。 作为一个领域驱动设计的实践者，我切实感受到了领域驱动为软件开发带来的好处，同时在实践领域驱动的过程中也感受到了困难，这种困难体现在工程实践的方方面面，例如什么是领域驱动的最佳设计？ 如何把书本上的设计灵活的应用在自己的项目上？如何跟团队成员就设计达成一致？ 本文尝试从领域驱动设计的目的出发，试图通过简单的描述来说明领域驱动设计的思想。 ，在领域驱动设计中讲究通过领域逻辑来驱动设计和开发工作，而不是通过数据库模型来驱动开发。 ---- 领域模型的持久化 在领域建模以及之前的步骤中，我们都没有提及数据库，因为领域驱动设计的核心是用代码建立一个共享模型，而数据库设计根本就不是领域驱动设计关心的内容。
83010发布于 2020-11-25 - 来自专栏IT技术订阅
领域驱动设计-上
DDD基础 引言 <<领域驱动设计-软件核心复杂性应对之道>>：全书围绕着设计和开发实践，结合若干真实的项目案例，向读者阐述如何在真实的软件开发中应用领域驱动设计。 为什么是领域模型的设计而不是架构设计或其他的什么设计呢？因为DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。 每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题。领域模型设计只是整个软件设计中的很小一部分。 领域驱动设计和微服务的关系：微服务架构怎么拆、拆多小？领域驱动设计定义领域模型，从而划分领域边界，然后再根据我们的领域边界从业务的角度去进行微服务边界定义。 领域驱动用什么方式进行边界的定义？ 设计 DDD中的设计主要指领域模型的设计，DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。
90110编辑于 2022-06-23
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号