DDD018-领领域驱动设计基础概念
领域驱动设计是程序员Eric Evans在 2004 年在他的著作《领域驱动设计:解决软件核心的复杂性》中引入的概念。
这是一种通过自上而下的方法查看软件来构建软件设计的方法。在详细讨论主题之前,让我们尝试集中一些光,并了解在此上下文中领域的含义。
什么是领域? 软件开发中使用的"领域"一词是指业务。在应用开发过程中,常用术语领域逻辑或业务逻辑。基本上,商业逻辑是应用逻辑围绕的知识领领域。应用程序的业务逻辑是一套规则和准则,解释业务对象应如何相互交互以处理建模数据。
注 : 软件工程领领域的一个领领域是应用程序打算建立的业务。
领域驱动设计: 假设我们已经设计了软件使用所有最新的技术堆栈和基础设施,我们的软件设计架构是神话般的,但当我们在市场上发布这个软件,它最终是由最终用户谁决定我们的系统是否伟大。此外,如果系统不能解决业务需求,对任何人都没有用处:无论它看起来多么漂亮,或者它的基础设施架构有多好。Eric Evans认为,当我们开发软件时,我们的重点不应该主要放在技术上,而应该主要放在商业上。
领域驱动设计涉及两种设计工具,第一种是战略设计工具,另一种是战术设计工具。程序员或开发人员通常处理战术设计工具,但如果我们对战略设计工具有知识和良好的理解,那么它将帮助我们构建良好的软件。
Spring 数据系列下的大部分框架都是在考虑领域驱动设计方法的情况下构建的。
战略设计: 战略设计工具帮助我们解决与软件建模相关的所有问题。这是一种类似于对象导向设计的设计方法,我们被迫从对象的角度进行思考。因此,在战略设计方面,我们不得不从背景的角度进行思考。
上下文: 我们可以将此视为一个英语单词,它指的是事件、事件、陈述或想法的情况,并且可以确定其含义。 除了上下文,战略设计还涉及模型、无处不在的语言和边界上下文。这些是用于领域驱动设计战略设计的常用术语。让我们逐一了解每一个。
- 模型 - 它作为一个核心逻辑,并描述了领域的选定方面。它用于解决与该业务相关的问题。
- 统一语言 - 所有团队成员使用的共同语言来连接团队围绕领域模型的所有活动。在与领域专家和团队成员交谈时,考虑它就像使用常见的动词和名词来处理类、方法、服务和对象一样。
- 边界上下文 - 它指的是上下文的边界条件。它是边界的描述,并作为一个阈值,其中,特定的领域模型被定义和适用。
战术设计: 战术设计谈实施细节,即建模领领域。它通常负责边界上下文中的组件。我们可能听说过或使用过诸如服务、实体、仓库和工厂之类的东西。它们都由领域驱动设计创造并广受欢迎。战术设计过程发生在产品开发阶段。
让我们来讨论一些重要的战术设计工具。这些工具是可用于创建和修改领域模型的高级别概念。
-
实体 • 从事对象导向原则工作的程序员可能知道称为类和对象的概念。在这里,实体是具有某些属性的类。这些类的例子具有全球特性,并在整个生命周期中保持相同的身份。请记住,财产状况可能会发生变化,但身份永远不会改变。简言之,实体执行某些业务逻辑,并且可以使用 ID 进行唯一识别。在编程方面,它通常作为行在 DB 中持续存在,并且它由值对象组成。
-
值对象 - 这些是不可变的轻质对象,没有任何身份。值对象通过执行复杂的计算来降低复杂性,将重计算逻辑与实体隔离。
在上述图像中,用户是一个实体,地址是一个值对象,地址可以更改多次,但用户的身份永远不会更改。每当地址得到更改,然后新地址将被刻录并分配给用户。
-
服务 - 服务是一个无状态类别,适合实体或价值对象以外的其他地方。简言之,服务是存在于实体和值对象之间的功能,但它既与实体无关,也不与对象值相关。
-
聚合 - 当我们有更大的项目,对象图变得大,更大的对象图更难维护它。聚合是单个交易边界下的实体和值的集合。基本上聚合,控制变化,并有一个根实体称为聚合根。根实体管理其他实体的寿命。
在上述示例中,如果根实体用户或订单被删除,则与根实体关联的其他实体将毫无用处,此关联信息也将被删除。这意味着聚合在性质上始终是一致的,并且这是在领域事件的帮助下完成的。生成领域事件以确保最终的一致性。 在上面的例子中,如果用户地址已更改,则必须将其反映在"顺序"中。为此,我们可以从用户到订单启动领域事件,以便订单更新地址,以便我们最终具有一致性,订单最终将保持一致。
聚合和聚合根的其他示例可能是对帖子的评论、问答详细信息、银行交易详细信息等。ORM 工具(如冬眠)使用聚合物很多,同时创建一对多或多对一的关系。
-
工厂和仓库 - 工厂和仓库用于处理聚合。工厂帮助管理聚合物生命周期的开始,而存储库帮助管理聚合物的生命周期的中间和末端。工厂帮助创建聚合物,而存储库帮助保持聚合。我们应该始终创建每个聚合根的存储库,但不是针对所有实体。
工厂是 GoF 的设计模式,工厂是有用的,但在聚合规则中不是强制性的。
领域驱动设计的优势:
- 它改进了我们的工艺。
- 它提供了灵活性
- 它更喜欢领域而不是界面
- 它通过无处不在的语言缩小团队之间的沟通差距
领域驱动设计的缺点:
- 它需要具有强大领域名专业知识的专业人员
- 它鼓励团队遵循迭次实践
- 原文作者:知识铺
- 原文链接:https://geek.zshipu.com/post/DDD/DDD018-%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1%E5%9F%BA%E7%A1%80%E6%A6%82%E5%BF%B5/
- 版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可,非商业转载请注明出处(作者,原文链接),商业转载请联系作者获得授权。
- 免责声明:本页面内容均来源于站内编辑发布,部分信息来源互联网,并不意味着本站赞同其观点或者证实其内容的真实性,如涉及版权等问题,请立即联系客服进行更改或删除,保证您的合法权益。转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com