DDD概念以及微服务划分

这篇具有很好参考价值的文章主要介绍了DDD概念以及微服务划分。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

DDD简介:

DDD与微服务的区别:

DDD核心概念:

如何划分微服务边界:


DDD简介:

DDD 是 Domain-Driven Design 的缩写,称为领域驱动设计。它是为了解决划分业务边界的问题,是一种架构模式,也是一种划分业务领域范围的方法论。

DDD与微服务的区别:

DDD 是一种架构设计方法,微服务是一种架构风格。两者从本质上都是为了追求高响应力,而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发,其核心要义是强调根据业务发展,合理划分领域边界,持续调整现有架构,优化现有代码,以保持架构和代码的生命力,也就是我们常说的演进式架构。

DDD 主要关注:从业务领域视角划分领域边界,构建通用语言进行高效沟通,通过业务抽象,建立领域模型,维持业务和代码的逻辑一致性。

微服务主要关注:运行时的进程间通信、容错和故障隔离,实现去中心化数据管理和去中心化服务治理,关注微服务的独立开发、测试、构建和部署。

DDD核心概念:

领域:是一种特定的范围,用来确定边界的。如电商领域、外卖配餐领域、保险领域等等。

子域:子域是领域的细分,子域还可以再继续细分,成为子域的子域。如电商领域的订单、商品、物流等子域。子域根据重要性和功能划分为三类子域,它们分别是:

核心域:决定产品和公司核心竞争力的子域。

通用域:没有太多个性化的诉求,同时被多个子域使用的通用功能子域。

支撑域:不包含决定产品和公司核心竞争力的功能,也不包含通用功能的子域。

领域的核心思想就是将问题域逐级细分,来降低业务理解和系统实现的复杂度。通过领域细分,逐步缩小微服务需要解决的问题域,构建合适的领域模型,而领域模型映射成系统就是微服务了。

通用语言:通过团队交流达成共识的,能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。通用语言会贯穿整个项目设计过程,并且体现在代码命名中,能够将业务需求准确转化为代码设计。通用语言在不同语境会产生不同的意思,需要在特定的上下文中使用。

限界上下文Bounded Context:用来封装通用语言和领域对象,提供上下文环境,保证在领域之内的一些术语、业务相关对象等(通用语言)有一个确切的含义,没有二义性。这个边界定义了模型的适用范围,使团队所有成员能够明确地知道什么应该在模型中实现,什么不应该在模型中实现。

理论上限界上下文是微服务设计和拆分的主要依据,但还需考虑团队、技术等外部因素

实体Entity:拥有多个属性、操作或行为的载体,并且有唯一标识符,有唯一id的一类对象。

值对象ValueObject:实际是一种不变的数据集合,与实体一起构成聚合。如地理位置、行政区划、币种、行业、职位等;体现在程序中就是常量、枚举、数据字典。

(可变性是实体的特点,而不变性则是值对象的本质。)

充血模型:模型对象不仅仅是一个数据结构,还包含了业务逻辑和操作数据的方法。好处是将业务逻辑和数据操作封装在一个对象中,使得代码逻辑更加清晰。

充血模型对开发人员有更高的能力要求,要有较强的团队协作能力,有强大的技术中台支撑

贫血模型:与充血模型相比,贫血模型就比较简单与直接。所有业务处理过程都交给 Service 去完成。

工厂:主要的工作是通过装配,创建领域对象。

仓库:为了解耦应用逻辑和基础资源,在基础层和上层应用逻辑之间会增加一层,这一层就是仓储层。

通过仓库与工厂实现聚合,对原有的 DAO 进行了一层封装,在保存、装载、查询等操作中,加入聚合、装配等操作。并将这些操作封装起来,对上层的客户程序屏蔽。这样,客户程序不需要以上这些操作,就能完成领域模型中的各自业务。技术门槛降低了,变更与维护也变得简便了。

聚合:代表在真实世界中的整体与部分的关系。比如,Order(订单)与 OrderItem(订单明细)就是一个整体与部分的关系。当加载一个订单时,应当同时加载其订单明细,而保存订单时应当同时保存订单与订单明细,并放在同一事务中。订单与客户、客户地址等信息不存在聚合关系。

聚合根:把聚合比作组织,那聚合根就是这个组织的负责人。聚合根也称为根实体,它不仅是实体,还是聚合的管理者。聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制,而导致聚合、实体之间数据不一致性的问题。

事件风暴(会议):通常产研与业务人员一起,通过头脑风暴会议,首先列出所有可能的业务行为和事件,然后找出产生这些行为的领域对象,并梳理领域对象之间的关系,找出聚合根,找出与聚合根业务紧密关联的实体和值对象,再将聚合根、实体和值对象组合,构建聚合。

如何划分微服务边界:

以前刚开始学微服务的时候,都是使用了电商微服务例子,一上来就是

1.用户微服务:负责用户信息的管理,包括用户的积分属性。

2.支付微服务:负责订单支付相关的具体业务。

3.商品微服务:负责商品的展示,推荐,搜索逻辑。

4.订单微服务:负责订单创建,管理,积分抵扣优惠券等实际商品价格的逻辑。

5.库存微服务:负责商品库存管理。

6.物流微服务:负责该订单商品的物流服务。

然后每个微服务使用不同的数据库,每个库有不同的表,我愿称之为”电商架构设计规范“,但是从来不知道这个规范是怎么来的。

假如换了个场景,不再是做电商平台,而是做微博、支付平台、广告平台、物联网等等场景的微服务呢,又该如何划分微服务边界?可以遵循什么规范?

选择DDD领域驱动设计划分微服务边界!

我们可以用三步来划定领域模型和微服务的边界。

第一步:在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等,根据这些要素梳理出领域实体等领域对象。

第二步:根据领域实体之间的业务关联性,将业务紧密相关的实体进行组合形成聚合,同时确定聚合中的聚合根、值对象和实体。在这个图里,聚合之间的边界是第一层边界,它们在同一个微服务实例中运行,这个边界是逻辑边界,所以用虚线表示。

第三步:根据业务及语义边界等因素,将一个或者多个聚合划定在一个限界上下文内,形成领域模型。在这个图里,限界上下文之间的边界是第二层边界,这一层边界可能就是未来微服务的边界,不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行,物理上相互隔离,所以是物理边界,边界之间用实线来表示。

有了这两层边界,微服务的设计就不是什么难事了。

在战略设计中我们建立了领域模型,划定了业务领域的边界,建立了通用语言和限界上下文,确定了领域模型中各个领域对象的关系。到这儿,业务端领域模型的设计工作基本就完成了,这个过程同时也基本确定了应用端的微服务边界。

在从业务模型向微服务落地的过程中,也就是从战略设计向战术设计的实施过程中,我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系,将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时,系统架构也会同时发生调整,并同步建立新的映射关系。

ddd和微服务架构,系统架构,DDD,微服务拆分,系统架构

学习摘录《DDD实战课》、《DDD微服务落地实战》文章来源地址https://www.toymoban.com/news/detail-632274.html

到了这里,关于DDD概念以及微服务划分的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 软件架构演进过程与微服务设计中的领域驱动设计(DDD)

    软件架构的演进是一个不断改进和解决问题的过程。从传统架构到面向服务架构(SOA),再到微服务架构,每个阶段都带来了新的技术和解决方案。而在微服务架构中,领域驱动设计(DDD)起着至关重要的作用,它能够提高系统的可扩展性、可维护性和可理解性。本文将介绍软件架

    2024年02月16日
    浏览(44)
  • 【DDD分布式系统学习笔记】RPC调用以及系统初步搭建

    modelVersion: 模型版本,指定POM模型的版本,目前使用的是Maven 4.0.0版本。 groupId: 项目的组织标识符,通常是组织的域名倒序。在这里是 cn.itedus.lottery。 artifactId: 项目的唯一标识符,通常是项目的名称。在这里是 Lottery。 packaging: 项目的打包方式,这里是 pom,表示这是一个聚合

    2024年01月18日
    浏览(51)
  • 设计一个亿级高并发系统架构 - 12306火车票核心场景DDD领域建模

    “ 架设一个亿级高并发系统,是多数程序员、架构师的工作目标。 许多的技术从业人员甚至有时会降薪去寻找这样的机会。但并不是所有人都有机会主导,甚至参与这样一个系统。今天我们用12306火车票购票这样一个业务场景来做DDD领域建模。” 要实现软件设计、软件开发

    2024年02月03日
    浏览(51)
  • DDD中的分层架构

    领域区域设计的分层架构模型其实是在不断优化和发展的,从最早的传统直肠子式的四层架构模型,逐渐演变成目前以依赖倒置为原则的新的四层架构模型,从而实现了各层对基础设施层的解耦。 DDD中的分层架构很好的应用了关注点分离原则Separation of Concerns(SOC),每一层做

    2024年02月12日
    浏览(41)
  • 一文了解DDD分层架构演进

    将领域模型和业务逻辑分离出来,并减少对基础设施、用户界面甚至应用层逻辑的依赖,因为它们不属业务逻辑。将一个夏杂的系统分为不同的层,每层都应该具有良好的内聚性,并且只依赖于比其自身更低的层。 传统分层架构的 基础设施层 位于底层,持久化和消息机制便

    2024年02月12日
    浏览(42)
  • Android 下一代架构指南:DDD

    移动端架构与网站架构的区别是什么?网易新闻客户端的架构演进历程是怎样的?为什么要选择 DDD 思想来指导重构?DDD 落地中应当关注哪些方面?带着这些问题我们来看下文。(节选自网易新闻App架构重构实践) 当前,大多数移动开发团队选择以 MVP 作为业务层的核心架构

    2023年04月10日
    浏览(61)
  • 【架构】领域驱动设计(DDD)的几种典型架构介绍

    我们生活中都听说了DDD,也了解了DDD,那么怎么将一个新项目从头开始按照DDD的过程进行划分与架构设计呢? 各种服务 IAAS:基础设施服务,Infrastructure-as-a-service PAAS:平台服务,Platform-as-a-service SAAS:软件服务,Software-as-a-service 从图中已经可以很容易看出架构的演进过程,

    2024年02月11日
    浏览(37)
  • DDD架构为什么应该首选六边形架构?

    分层架构的一个重要原则是:每层只能与位于其下方的层发生耦合。 分层架构分两种:一种是严格分层架构,规定某层只能与直接位于其下方的层发生耦合;另一种是松散分层架构,允许任意上方层与任意下方层发生耦合。 下图是一个典型的DDD传统分层架构。 以上分层架构

    2024年02月16日
    浏览(56)
  • 领域驱动设计DDD架构解析和绘图模板分享

    DDD整洁架构 DDD整洁架构为了解决强调用的关系,出现了 洋葱架构(六边形)架构 ,就是为了实现 依赖倒置 它的思想就是把领域模型放到核心的位置, 领域模型 是独立的,不会直接强依赖其他层,而通过 适配器 来完成领域模型和外层的数据交换。 DDD分层架构和三层架构的

    2024年02月05日
    浏览(76)
  • 【实践篇】领域驱动设计:DDD工程参考架构

    不同团队落地DDD所采取的应用架构风格可能不同,并没有统一的、标准的DDD工程架构。有些团队可能遵循经典的DDD四层架构,或改进的DDD四层架构,有些团队可能综合考虑分层架构、整洁架构、六边形架构等多种架构风格,有些在实践中可能引入CQRS解决读模型与写模型的差异

    2024年02月05日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包