DDD兴起的原因以及与微服务的关系
首页>>云原生>>正文

目录


    DDD为什么能火起来?


    我们先不讨论DDD的定义,先梳理一下DDD火起来的背景,根据我学习的套路,永远是为什么为先,再是解决什么问题,是什么东西,最后如何使用。我们都知道这些年随着设备以及技术的发展,软件架构发生了很多变化,从最初的单机(BS/CS)架构到后面的集中式架构,再到如今的微服务架构,现在基本可以说是微服务架构盛行的时代,DDD早在2004年就由埃里克·埃文斯提出,但一直处于一个不愠不火的状态,直到Martin Fowler的《Microservices》引起大家注意,也就是微服务盛行之后(这儿需要说明的是,微服务最早的提出者不是Martin Fowler,而是Fred George),DDD再次回到人们视野中间,为什么呢?

    我们先看一下三种技术架构的演进以及主要区别:


    第一阶段是单机架构,特征是整个开发围绕着数据库进行设计和开发。

    第二个阶段是三层式的集中式架构,采用面向对象的设计方法,业务逻辑分业务层、逻辑层、数据访问层,这种架构很容易某一层或者几层变得臃肿,扩展性较差,另外摩尔定律失效,单台机器性能有限。

    第三层阶段是微服务架构,在集中式架构中,系统分析、设计和开发往往是独立进行的,而且各个阶段负责人可能不一样,那么就涉及到交流信息丢失的问题,另外项目从分析到开发经历的流程很长,很容易最终开发设计与需求实现的不一样,微服务主要就是解决第二阶段的这些痛点,实现应用之间的解耦,解决单体应用扩展性的问题。


    微服务存在的问题


    进入微服务之后,解决了集中式架构的单体应用很多问题,但是新的问题应运而生,微服务的粒度应该多大?微服务如何设计呢?微服务如何拆分?微服务边界在哪里?

    很长时间人们都没有解决这一问题,就连Martin Fowler在提出微服务架构的时候也没有告诉我们这该如何拆分微服务。

    甚至在很长的时间里人们对微服务拆分产生了一些误解,有人认为:“微服务很简单,就是将之前的单体应用拆分成多个部署包,或者将原来的单体应用架构替换为一套支持微服务的技术架构,就算是微服务了。”还有人认为微服务应该拆分得越小越好。

    鉴于上述情形,很多项目因为前期拆分过度,导致复杂度过高,导致后期难以运维甚至难以上线。

    可以得出一个结论:微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说,确定了业务边界和应用边界,这个困境也就迎刃而解了。

    而DDD就是解决了这个确定业务边界的问题,可见DDD并不是一种技术架构,而是一种划分业务领域范围的方法论。DDD的兴起是由于很多熟悉领域驱动建模(DDD)的工程师在进行微服务设计时,发现用DDD的思路进行业务梳理可以很好规划服务边界,可以很好实现微服务内部和外部的“高内聚、低耦合”。于是越来越多的人将DDD作为业务划分的指导思想。

    那么,什么是DDD呢?


    DDD概述


    通过上文的学习就可以知道DDD是一种拆解业务、划分业务、确定业务边界的方法,是一种高度复杂的领域设计思想,将我们的问题拆分成一个个的域,试图分离技术实现的复杂性,主要解决的是软件难以理解难以演进的问题,DDD不是一种架构,而是一种架构方法论,目的就是将复杂问题领域简单化,帮助我们设计出清晰的领域和边界,可以很好的实现技术架构的演进。DDD包括两部分,战略设计部分和战术设计部分。

    战略设计主要从业务视角出发,建立业务领域模型,划分领域边界,建立通用语言的限界上下文,限界上下文可以作为微服务设计的参考边界。

    战术设计则从技术视角出发,侧重于领域模型的技术实现,完成软件开发和落地,包括:聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

    DDD战略设计会建立领域模型,这四个字放一起会让人觉得很高深,其实是纸老虎,通俗来说就是模拟某个领域的的一种模型,这个模型比较抽象,但便于人们交流,举个例子:公园有一棵桃树,如果我们想好好研究桃树该怎么研究?

    桃子好吃吗?贵不贵?品种?怎么种植?种在什么地方?做成桃木剑?桃子树叶药用价值?

    你看,这样研究每一个问题都很有道理,但是又很混乱,再回忆一下初中生物书上是这么研究的?

    先将植物根据大家的理解分成多个器官组成,像桃子、桃叶、桃花等等,然后将每一个器官再根据功能细分成组织,再根据这个组织中各个细胞的形态等作用分成不同的细胞,你看看这是不是一种很有条理的分析方法。


    DDD也是如此,当我们面对桃树这种复杂的业务的时候,先根据固有的认识分成多个器官(领域),然后再在每一个领域中根据某些维度(这儿是功能)分为多个组织(聚合),而每一个组织中由很多细胞(实体)组成,这就是一种战略,有哪些好处呢?可以确保我们讨论的边界,也就是讨论的东西是一个领域一个维度的,对于桃树来说,桃子、桃花、桃叶、树干都是不同的领域,划分不同领域的就是边界,我们这儿叫领域边界,当我们确定好这些领域之后,就可以确保我们讨论的是同一个领域部分的东西,这样的好处就是我们可以规定好一些概念,或者说术语,以后大家讨论的时候就尽可能少的信息丢失。

    DDD战略设计会建立领域模型,领域模型用来指导微服务的设计和拆分,DDD第一步要做的就是来一个头脑风暴,可以理解成一起讨论对业务的理解,主要目的就是尽可能前面不遗漏的分解我们的业务领域,就好比刚刚的桃树,最先要做的就是尽可能多的分析,确保每一个领域都可以被关注到,在实践中,往往会采用用例分析、场景分析和用户旅程分析,这是一个发散的过程,头脑风暴阶段会产生很多实体、命令、事件等领域对象,我们从不同的维度对进行聚类形成聚合、限界上下文等边界,建立领域模型,这是一个收敛的过程。


    具体来说,我们可以通过三步来确定领域模型和微服务边界。

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

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

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

    上面除了领域、聚合、实体外还出现了聚合根、值对象等词语,除此之外还有统一建模语言、子域、核心域、通用域、支撑域等,其实都是纸老虎,前面说过了为了方便对于某个领域的讨论往往会形成一些概念,这些概念会有一些名词概括,上面的名词就是这么来的,这就叫统一建模语言,哈哈哈,好了,不扯淡,我后面的文章会解释下这些词语的意思,这儿主要讨论DDD解决什么了问题。

    梳理一下DDD与微服务的关系,DDD是一种架构设计方法,微服务是一种架构风格,两者从本质上都是为了追求高响应力,而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发,其核心要义是强调根据业务发展,合理划分领域边界,持续调整现有架构,优化现有代码,以保持架构和代码的生命力,也就是我们常说的演进式架构。DDD主要关注:从业务领域视角划分领域边界,构建通用语言进行高效沟通,通过业务抽象,建立领域模型,维持业务和代码的逻辑一致性。

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


    总结


    这篇文章主要研讨了DDD火起来的原因,解决了什么业界难题,知道DDD主要思路,以及DDD大概的实现步骤等。

    留个小问题:单体应用适合DDD吗?

    原文链接:https://www.cnblogs.com/Courage129/p/14839544.html


    Kubernetes管理员(CKA)培训


    本次培训在北京开班,基于最新考纲,通过线下授课、考题解读、模拟演练等方式,帮助学员快速掌握Kubernetes的理论知识和专业技能,并针对考试做特别强化训练,让学员能从容面对CKA认证考试,使学员既能掌握Kubernetes相关知识,又能通过CKA认证考试,学员可多次参加培训,直到通过认证。点击下方图片或者阅读原文链接查看详情。


    给TA打赏
    共{{data.count}}人
    人已打赏

    相关文章

    eBPF、sidecars 和服务网格的未来

    eBPF、sidecars 和服务网格的未来

    eBPF 最近很火热,因为可以为云原生世界提供很多东西。由于 Cilium 之类的项目,它一直是 Kubernetes 集群的 CNI 层的流行选择。Linkerd 等服务网格通常与 Cilium 等 CNI 层一起部署,将 Linkerd 强大的 L7 处理与 Cilium 超快的 L3/4 处理相结合。 但是,eBPF 的网络技术到底有多强大?例如,它能否让我们完全替换 Linkerd 的 sidecars 代理,而只在内核中做所有事情? 在本文中,我将尽我所能评估这种可能性——尤其是当它与对用户的影响有关时。

    Kalix:构建无服务器的云原生业务关键型应用程序,无需数据库

    Kalix:构建无服务器的云原生业务关键型应用程序,无需数据库

    Akka 背后的公司Lightbend最近推出了 Kalix,这是一种新的平台即服务产品,用于使用任何没有数据库的编程语言构建云原生、业务关键型应用程序。Kalix 是一个统一的应用层,它将编写软件所需的部分汇集在一起,并抽象出它们的实现细节。Lighbend 旨在为开发人员提供“创新的 NoOps 开发人员体验”。 Lightbend 的创始人兼首席执行官Jonas Bonér解释了 Kalix 的动机: 云生态系统的复杂性正在减缓工程和开发团队的速度。Kubernetes在管理、编排和确保容器的可用性和可扩展性

    英特尔进军比特币挖矿设备市场

    英特尔进军比特币挖矿设备市场

    本文由半导体产业纵横综合   英特尔总部位于加利福尼亚州圣克拉拉   英特尔公司的新比特币挖矿芯片可能会成为多年来主导市场的中国挖矿设备制造商的第一个主要挑战者。   这家总部位于加利福尼亚州圣克拉拉的芯片制造巨头本月早些时候公布了其加密挖矿计划,并于1月份推出了第一代Bonanza Mine芯片。Jack Dorsey 的数字支付公司Block Inc.以及两家矿业公司Griid Infrastructure 和Argo Blockchain将在今年晚些时候收到第一批芯片。 &nbs

    浅谈铁电存储器:如何实现下一代内存计算?

    浅谈铁电存储器:如何实现下一代内存计算?

    本文由半导体产业纵横编译自technews 因应人工智能、物联网、5G、车载等新兴科技所迎来的巨量资讯分析需求,近年来各国政府及国际知名大厂皆积极地投注大量资源,加速开发兼具提升运算速度以及降低耗能的下世代存储器。而新兴存储器技术选项中,当属铁电存储器最被看好,其原理、技术挑战与未来机会为何?(本文出自中国台湾清华大学工程与系统科学系巫勇贤教授,于闳康科技“科技新航道合作专栏”介绍《铁电存储器的原理、挑战与展望》文稿,经科技新报修编为上下两篇,此篇为上篇。)    Memory-Centric
    后端开发

    CentOS 的替代品 Rocky Linux 现已正式发布

    2021-6-21 15:00:10

    云原生后端开发

    OCI 分发规范 v1.0重磅发布:容器生态系统更加标准

    2021-6-26 15:54:14

    0 条回复 A文章作者 M管理员
      暂无讨论,说说你的看法吧
    个人中心
    购物车
    优惠劵
    今日签到
    有新私信 私信列表
    搜索