杭州百度推广网站建设,北京网站建设好,低代码平台 开源,阿里云服务器怎么建网站一、软件设计发展过程二、什么是DDD#xff1f;2.1 战略设计2.2 战术设计2.3 名词扫盲1. 领域和子域2. 核心域、通用域和支撑域3. 通用语言4. 限界上下文5. 实体和值对象6. 聚合和聚合根 2.4 事件风暴2.5 领域事件 三、DDD与微服务3.1 DDD与微服务的关系3.2 基于DDD进行微服务… 一、软件设计发展过程二、什么是DDD2.1 战略设计2.2 战术设计2.3 名词扫盲1. 领域和子域2. 核心域、通用域和支撑域3. 通用语言4. 限界上下文5. 实体和值对象6. 聚合和聚合根 2.4 事件风暴2.5 领域事件 三、DDD与微服务3.1 DDD与微服务的关系3.2 基于DDD进行微服务设计3.3 基于DDD重构中台业务模型1. 自顶向下2. 自底向上 四、总结 一、软件设计发展过程 软件架构模式大体上经历了从单机架构 - 集中式架构 - 分布式微服务三个阶段的架构演进。 在单机和集中式架构模式下软件无法快速响应需求和业务的迅速变化直到微服务架构时代的来临。微服务架构解决了单机和集中式架构的很多问题比如扩展性、弹性伸缩性、小规模团队的敏捷开发等。 但是带来好处的同时微服务实践过程中也产生了不少争议性的问题“微服务到底应该怎么拆分和设计才算合理拆多小才叫微服务”而微服务的边界历来也是最容易产生争议的地方。 二、什么是DDD 2004年埃里克·埃文斯发表了《领域驱动设计》这本书DDD(Domain Driven Design)由此诞生。 DDD核心思想是通过领域驱动设计方法定义领域模型从而确定业务和应用边界保证业务模式和系统架构模式的一致性。 DDD不是架构而是一种架构设计方法论它通过边界划分将复杂的业务领域简单化从而设计出清晰的领域和应用边界进而可以非常容易地实现架构演进。 DDD主要包括战略设计和战术设计两大部分。 战略设计主要从业务视角出发建立业务领域模型划分领域边界建立通用语言的限界上下文而限界上下文可以作为微服务划分的主要参考边界。战术设计主要从技术视角出发侧重于领域模型的技术实现完成软件开发的落地包括聚合、聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。 2.1 战略设计 DDD 战略设计主要从业务视角出发建立业务领域模型领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法它是一个从发散到收敛的过程。 什么是事件风暴 事件风暴是一种协作的过程通常采用用例分析、业务场景分析和用户旅程分析等尽可能全面不遗漏地分解业务领域并梳理领域对象之间的关系这是一个发散的过程。事件风暴过程会产生很多实体、命令、事件等领域对象通过将这些领域对象从不同维度进行聚类将数据集中的对象或数据点按照某种相似性或相关性的标准分成不同的组别即“簇”。聚类的目标是将相似的数据点分到同一簇中使得同一簇内的数据点之间更加相似而不同簇之间的数据点相对较不相似。形成聚合、聚合根、限界上下文等边界建立领域模型这是一个收敛的过程。 事件风暴可以帮助开发团队、业务团队共同理解和共享对业务领域的见解有助于捕获关键的业务事件(领域事件)、过程和概念以指导软件系统的设计和实施从而更好地支撑业务需求落地。此外事件风暴有助于提高团队的沟通、协助和业务理解能力。 在战略设计中建立了领域模型划定了业务领域的边界并建立了通用语言和限界上下文确定了领域模型中各个领域对象的关系如上图所示。 2.2 战术设计 当领域模型的设计工作完成后基本也就确定了应用端的微服务边界。在从领域模型向微服务架构设计落地的过程中也就是从战略设计向战术设计的实施过程中开发人员会将领域模型中的领域对象聚合、聚合根、实体、值对象等与代码模型中的对象建立映射关系可以通过表格进行罗列记录将业务架构和系统架构进行绑定。 战术设计则从技术视角出发侧重于领域模型的技术实现完成软件开发和落地包括聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。 经验 可通过 Excel 表格记录、罗列战术设计中的聚合根、实体、值对象等关系、属性 2.3 名词扫盲 DDD 的知识体系提出了很多的名词像领域、子域、核心域、通用域、支撑域、通用语言、限界上下文、聚合、聚合根、实体、值对象等等非常多下面一一进行解释。 1. 领域和子域 领域指的是一个特定业务领域或问题领域它通常涉及一组相关的业务规则、概念和数据。领域可以进一步划分为子领域我们把划分出来的多个子领域称为子域每个子域对应一个更小的问题域或更小的业务范围。 2. 核心域、通用域和支撑域 在领域不断划分的过程中领域会细分为不同的子域子域可以根据自身重要性和功能属性划分为三类子域它们分别是核心域、通用域和支撑域。 核心域决定产品和公司核心竞争力的子域。**核心域是业务成功的主要因素和公司的核心竞争力。**如平安的保险。通用域没有太多个性化诉求同时被多个子域使用的通用功能子域。如系统权限、合同。支撑域既不包含决定产品和公司核心竞争力的功能也不包含通用功能的子域。如数据字典系统。 3. 通用语言 在事件风暴的过程中领域专家、业务人员、开发人员会一起建立领域模型在领域建模的过程中会形成通用的业务术语和用户故事进而形成能够简单、清晰、准确描述业务含义和规则的通用语言。通用语言可以解决交流障碍问题使得领域专家、业务人员和开发人员能够更加高效的协同合作进而确保业务需求的正确表达与落地。 通用语言贯穿 DDD 的整个设计过程事件风暴 - 领域故事分析 - 提取领域对象 - 领域对象与代码模型映射 - 代码落地基于通用语言可以设计出可读性更好的代码将业务需求准确转化为代码设计。 4. 限界上下文 任何语言都存在语义环境的在不同的时空和背景下同一句话会存在不同的含义比如语言“衣服能穿多少就穿多少。”在夏天表就是要穿少一点儿冬天却表示需要穿的很多。所以DDD的通用语言也存在它的语义环境为了避免同样的概念或语义在不同的环境中产生企业DDD提出了 限界上下文 用来确定语义所在的领域边界。限界上下文可以通过将其拆分为限界、上下文来进行理解。 限界领域的边界上下文语义环境 限界上下文是用来封装通用语言和领域对象提供上下文环境保证在领域内的一些术语、业务相关对象等有一个唯一的含义。例如在电商领域中商品在不同阶段存在不同的含义在销售、售卖时是商品在打包运输时则为货物所以在销售领域和运输领域之间存在限界上下文如下 限界上下文是微服务设计和拆分的主要依据它确定了微服务的设计和拆分方向在事件风暴中领域专家、架构师和开发人员的主要工作就是划分限界上下文。理论上可以将一个限界上下文设计为一个微服务当然还需根据其他限制因素考虑防止过度拆分。 5. 实体和值对象 实体和值对象都是用来表示领域模型中的事物或概念的重要元素。它们有不同的特性和用途。实体和值对象是组成领域模型的基础单元。 实体通常代表领域中的具体事务具体唯一标识、生命周期和状态并且可以被识别、跟踪和区分。领域模型中的实体是多个属性、操作或行为的载体。在事件风暴中我们可以根据命令、操作或事件找出产生这些行为的业务实体对象。值对象通常将多个相关属性组成的集合称为一个值对象。值对象没有唯一标识是不可变的通常用来表示领域中的属性和特性帮助描述实体的特性。 实体一般对应业务对象它具有业务属性和业务行为。而值对象主要是多个相关属性集合对实体的状态和特征进行描述。例如人员实体原本包括姓名、身份证号、性别、年龄以及所在省、市、县和街道等属性。我们可以将 “省、市、县和街道等属性” 抽离出来构建一个地址属性集合这个集合对象就是值对象。如下 一个实体可以存在多个值对象。 6. 聚合和聚合根 由业务和逻辑紧密关联的实体和值对象组合而成的对象称为聚合。聚合都存在一个聚合根和上下文边界。聚合是数据修改和持久化的基本单位。 聚合根如果把聚合比作组织那聚合根就是这个组织的 “头”。聚合根也称为根实体它不仅是实体还是聚合的管理者在聚合之间还是聚合对外的接口人以聚合根ID 关联的方式接受外部任务和请求在上下文内实现聚合之间的业务协同。聚合之间通过聚合根ID关联引用如果需要访问其他聚合的实体需要先访问聚合根再通过聚合根导航到聚合内部实体外部对象不能直接访问聚合内实体。上下文边界上下文边界根据业务单一职责和高内聚原则定义了聚合内部应该包含那些实体和值对象而聚合之间的边界是松耦合的。按照这种方式设计出来的微服务很自然就满足“高内聚、低耦合”的特点。 如何设计聚合 DDD 领域建模通常采用事件风暴通过用例分析、场景分析和用户旅程分析等方法列出所有可能的业务行为和事件然后找出产生这些行为的领域对象并梳理领域对象之间的关系找出聚合根找出与聚合根业务紧密关联的实体和值对象再将聚合根、实体和值对象组合构建聚合。 下面我们以大家都熟悉的学校选课业务场景为例看一下聚合的构建过程主要包括哪些步骤。 第一步采用事件风暴通过用例分析、场景分析和用户旅程分析等方法如下梳理出在选课过程中发生这些行为的所有的实体和值对象比如课程、老师、学生、选课规则、上课时间等等。 老师通过账号登录教务系统发布课程相关信息包括课程学分、上课地址、上课时间、选课规则等。学生通过账号登录教务系统进行选课。 第二步从众多实体中选出适合作为对象管理者的根实体既聚合根。 如何判断一个实体是否为聚合根可以通过是否有独立的生命周期是否有全局唯一ID 是否可以创建或修改其它对象是否有专门的模块来管这个实体。图中的聚合根分别是课程和用户实体。 第三步根据业务单一职责和高内聚原则找出与聚合根关联的所有紧密依赖的实体和值对象。构建出1个包含聚合根唯一、多个实体和值对象的对象聚合在图中我们构建了课程和用户这两个聚合。 第四步在聚合内根据聚合根、实体和值对象的依赖关系画出对象的引用和依赖模型。 第五步多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。 聚合的设计原则 单一职责聚合内的每个实体和值对象应该具有单一责任。它们应该专注于执行特定的任务而不应该包含不相关的功能。保持事务边界聚合应该定义一个明确的事务边界。这意味着所有聚合内的实体和值对象应该作为一个整体一起加载、保存和维护。在跨聚合的操作中事务应该在每个聚合内进行管理实现对象数据的一致性这就是聚合能实现业务高内聚的原因。通过唯一标识引用其它聚合聚合之间是通过关联外部聚合根ID 的方式引用而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理容易导致聚合的边界不清晰也会增加聚合之间的耦合度。设计小聚合如果聚合设计得过大聚合会因为包含过多的实体导致实体之间的管理过于复杂高频操作时会出现并发冲突或者数据库锁最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性让领域模型更能适应业务的变化。高内聚聚合内的实体和值对象应该具有高内聚性即它们应该紧密相关共同支持聚合的目标。 这些原则有助于创建具有高内聚性、低耦合性和良好一致性的聚合从而更好地管理领域中的复杂性。在DDD中良好的聚合设计有助于将复杂的领域问题划分为更容易管理和理解的单元。 2.4 事件风暴 事件风暴是一种协作的过程通常采用用例分析、业务场景分析和用户旅程分析等尽可能全面不遗漏地分解业务领域并梳理领域对象之间的关系这是一个发散的过程。事件风暴过程会产生很多实体、命令、事件等领域对象通过将这些领域对象从不同维度进行聚类将数据集中的对象或数据点按照某种相似性或相关性的标准分成不同的组别即“簇”。聚类的目标是将相似的数据点分到同一簇中使得同一簇内的数据点之间更加相似而不同簇之间的数据点相对较不相似。形成聚合、聚合根、上下文边界、限界上下文等边界建立领域模型这是一个收敛的过程。 事件风暴可以帮助开发团队、业务团队共同理解和共享对业务领域的见解有助于捕获关键的业务事件(领域事件)、过程和概念以指导软件系统的设计和实施从而更好地支撑业务需求落地。此外事件风暴有助于提高团队的沟通、协助和业务理解能力。事件风暴的过程可以大概分为以下几步 会议准备 确认会议参与者通常包括领域专家、业务领域、开发人员等明确风暴目标确定需要解决的具体业务问题或挑战以便确保风暴的焦点明确。会议进行 会议参与者一起聚焦本次会议需要解决的特定业务问题或理解领域概念。通常采用用例分析、业务场景分析和用户旅程分析 等尽可能全面不遗漏地分解业务领域。识别事件 团队开始识别与业务问题或领域相关的事件。事件是业务过程中的关键时刻或状态变化。每个事件都应该有一个名称例如“用户注册”或“订单支付”。绘制事件流 将事件以时间顺序的方式进行绘制以创建一个事件流。在事件流中每个事件都有自己的标记通常包括事件的名称、触发条件、内容和结果。事件之间可以使用箭头表示它们的顺序关系。添加领域概念 在事件风暴期间团队还会标识和讨论与事件相关的领域概念如聚合、聚合根、实体、值对象等。这有助于明确事件与领域中的关键概念之间的关系。讨论和澄清 团队成员之间会讨论事件和概念澄清不明确的地方确保大家对业务领域有一致的理解。可视化领域 通过可视化团队能够更好地理解和共享对业务领域的见解。事件和概念的可视化帮助团队在整个过程中保持一致性。生成模型 根据事件风暴的结果可以生成领域模型或其他文档用于指导软件系统的设计和开发。这些模型通常包括领域对象、聚合根、实体和事件。制定项目计划 最后团队制定项目计划包括开发、测试和迭代的任务等。 事件风暴是一种非常有用的工具用于在项目的早期阶段构建共享理解和对业务领域进行深入挖掘。它有助于软件团队更好地满足业务需求确保领域知识的一致性并提高团队协作的效率。 2.5 领域事件 在进行事件风暴时除了命令和操作等业务行为以外还有一种非常重要的事件这种事件发生后通常会导致进一步的业务操作例如当老师做完课程信息上传时需在某一个时间后通知学生进行选课在 DDD 中这种事件被称为领域事件。 领域事件是领域模型中非常重要的一部分用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作在实现业务解耦的同时还有助于形成完整的业务闭环。领域事件也是微服务解耦的关键。 领域事件可以是业务流程的一个步骤比如学生选课完成后触发学生当前学期课程列表动作也可能是定时批处理过程中发生的事件比如批处理选手选课情况触发选课邮件通知操作或者一个事件发生后触发的后续动作比如密码连续输错三次触发锁定账户的动作。 如何识别领域事件呢 在做用例分析、业务场景分析和用户旅程分析时我们要捕捉业务、需求人员或领域专家口中的关键词“如果发生……则……”、“当做完……的时候请通知……”、“发生……时则……”等。在这些场景中如果发生某种事件后会触发进一步的操作那么这个事件很可能就是领域事件。 领域事件有的发生在微服务内有的发生在微服务之间还有两者皆有的场景一般跨微服务的领域事件大多会用到消息中间件实现跨微服务的事件发布/订阅。消息中间件的产品非常成熟市场上可选的技术也非常多比如RabbitMQ、Kafka、RocketMQ等。 三、DDD与微服务 3.1 DDD与微服务的关系 DDD 是一种架构设计方法微服务是一种架构风格两者都强调从业务出发其核心要义是强调根据业务发展合理划分领域边界持续调整现有架构优化现有代码以保持架构和代码的生命力也就是我们常说的演进式架构。 DDD 主要关注从业务领域视角划分领域边界构建通用语言进行高效沟通通过业务抽象建立领域模型维持业务和代码的逻辑一致性。微服务主要关注服务设计、拆分运行时的进程间通信、容错和故障隔离实现去中心化数据管理和去中心化服务治理关注微服务的独立开发、测试、构建和部署。 DDD 强调领域模型和微服务设计的一体性先有领域模型然后才有微服务而不是脱离领域模型来谈微服务设计。首先通过DDD战略设计建立领域模型划分微服务边界每个边界都由一个或多个领域模型或聚合组成。然后通过战术设计将领域模型转化为微服务设计并进行落地。 3.2 基于DDD进行微服务设计 DDD 包括战略设计和战术设计两部分。 战略设计战略设计主要从业务视角出发建立业务领域模型划分领域边界建立通用语言的限界上下文限界上下文可以作为微服务设计的参考边界。 战略设计通过事件风暴通常采用用例分析、业务场景分析和用户旅程分析等找出领域对象和聚合根对实体和值对象进行聚类组成聚合划分限界上下文建立领域模型的过程。 战略设计主要包括产品愿景、用例分析、业务场景分析、用户旅程分析、领域建模和微服务拆分等几个主要过程。战略设计阶段建议参与人员领域专家、业务需求方、产品经理、架构师、项目经理、开发 经理和测试经理。 战术设计战术设计侧重于从技术视角出发根据领域模型进行微服务设计。这个阶段主要梳理微服务内的领域对象 梳理领域对象之间的关系确定它们在代码模型和分层架构中的位置建立领域模型与微服务模型的映射关系以及服务之间的依赖关系进而完成软件开发和落地主要包括聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。 战术设计包括以下两个阶段分析微服务领域对象和设计微服务代码结构。 分析微服务领域对象设计微服务代码结构 战术设计阶段建议参与人员领域专家、产品经理、架构师、项目经理、开发经理和测试经理等。 3.3 基于DDD重构中台业务模型 “中台” 是一种在软件和业务领域中经常使用的概念它涉及到软件系统和业务流程的架构和设计。 中台的核心思想是将系统或业务流程中的共享资源、功能和服务抽象成一个中间层以便多个应用程序或模块可以共享和重用这些资源。这种架构方法有助于提高系统的效率、可维护性和可扩展性同时减少了冗余工作和开发成本。 中台的设计思想与“高内聚、低耦合”的设计原则是高度一致的。高内聚是把相关的业务行为聚集在一起把不相关的行为放在其它地方按照“高内聚、松耦合”的原则实现企业级的能力复用。 中台的目标是通过资源共享、业务模块化、标准化接口和降低复杂度使企业的IT系统更具弹性更容易适应快速变化的业务需求。 将重复的需要共享的通用能力、核心能力沉淀到中台将分离的业务能力重组为完整的业务板块构建可复用的中台业务模型。中台业务建模有自顶向下和自底向上两种策略这两种策略有自己的适用场景你需要结合自己公司的情况选择合适的策略。 1. 自顶向下 自顶向下策略是先做顶层设计从最高领域逐级分解为中台分别建立领域模型根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设或旧系统推倒重建的情况。 由于这种策略不必受限于现有系统你可以用 DDD 领域逐级分解的领域建模方法。从下面这张图我们可以看出它的主要步骤 第一步是将领域分解为子域子域可以分为核心域、通用域和支撑域第二步是对子域建模划分领域边界建立领域模型和限界上下文第三步是根据限界上下文进行微服务设计。 2. 自底向上 自底向上种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模然后对齐业务域找出具有同类或相似业务功能的领域模型对比分析领域模型的差异重组领域对象重构领域模型。这个过程会沉淀公共和复用的业务能力会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。 如何采用自底向 上的策略来构建中台业务模型主要分为这样三个步骤。 第一步锁定各个系统所在业务域构建领域模型。 锁定各个系统所在的业务域采用事件风暴找出领域对象构建聚合划分限界上下文建立领域模型。那在构建中台业务模型时需要重点关注那些存在业务能力重复的领域模型将这些不同领域模型中重复的业务能力沉淀到中台业务模型中将分散的领域模型整合到统一的中台业务模型中对外提供统一的共享的中台服务。 第二步对齐业务域构建中台业务模型。 构建多业务域的中台业务模型的过程就是找出同一业务域内所有同类业务的领域模型对比分析域内领域模型和聚合的差异和共同点打破原有的模型完成新的中台业务模型重组或归并的过程。构建中台业务模型的要点总结成一句话就是“分域建模型找准基准域划定上下文聚合重归类。” 第三步中台归类根据领域模型设计微服务。 完成中台业务建模后就可以通过其领域模型中看到总共需要构建了多少个中台中台下面有哪些领域模型哪些中台是通用中台哪些中台是核心中台中台的基本信息等等都一目了然。最后就可以根据中台下的领域模型进行微服务的设计。 四、总结 我认为要想应用 DDD首要任务就是要吃透 DDD 的核心设计思想搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型微服务是业务模型的具体实现DDD 是一种设计思想它可以同时指导中台业务建模和微服务设计它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性先有领域模型然后才有微服务而不是脱离领域模型来谈微服务设计。DDD主要包括战略设计和战术设计两大部分。战略设计用于定义领域模型确定业务边界这对于中台和微服务的构建至关重要。在战术设计阶段你需要将领域模型映射到微服务设计中并严格遵循DDD原则确保微服务与领域模型保持一致性。 拥有一套清晰的微服务设计和拆分方法是确保微服务架构的成功的关键。这种方法可以帮助你建立清晰的微服务边界确保微服务系统的可维护性和可持续演进。 最终DDD、中台和微服务的结合可以为企业提供高度灵活性和创新性帮助他们更好地应对不断变化的市场需求。这种铁三角关系可以帮助企业建立坚实的技术基础实现持续增长和竞争优势。