长沙专业的建站按效果付费,wordpress 360字体大小,建立一个个人网站,深圳航空人工服务电话目录学好了DDD#xff0c;你能做什么#xff1f;领域驱动设计#xff1a;微服务设计为什么要选择DDD#xff1f;领域、子域、核心域、通用域和支撑域#xff1a;傻傻分不清#xff1f;限界上下文#xff1a;定义领域边界的利器实体和值对象#xff1a;从领域模型的基础… 目录学好了DDD你能做什么领域驱动设计微服务设计为什么要选择DDD领域、子域、核心域、通用域和支撑域傻傻分不清限界上下文定义领域边界的利器实体和值对象从领域模型的基础单元看系统设计聚合和聚合根怎样设计聚合领域事件解耦微服务的关键DDD分层架构有效降低层与层之间的依赖微服务架构模型几种常见模型的对比和分析中台数字转型后到底应该共享什么DDD、中台和微服务它们是如何协作的学好了DDD你能做什么我认为要想应用 DDD首要任务就是要吃透 DDD 的核心设计思想搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型微服务是业务模型的系统落地DDD 是一种设计思想它可以同时指导中台业务建模和微服务设计它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性先有领域模型然后才有微服务而不是脱离领域模型来谈微服务设计。其次就是通过战略设计建立领域模型划分微服务边界。最后通过战术设计我们会从领域模型转向微服务设计和落地。DDD 的核心知识体系领域驱动设计微服务设计为什么要选择DDD我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说确定了业务边界和应用边界这个困境也就迎刃而解了。DDD 是一种处理高度复杂领域的设计思想它试图分离技术实现的复杂性并围绕业务概念构建领域模型来控制业务的复杂性以解决软件难以理解难以演进的问题。DDD 不是架构而是一种架构设计方法论它通过边界划分将复杂业务领域简单化帮我们设计出清晰的领域和应用边界可以很容易地实现架构演进。DDD 战略设计会建立领域模型领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析尽可能全面不遗漏地分解业务领域并梳理领域对象之间的关系这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象我们将这些领域对象从不同的维度进行聚类形成如聚合、限界上下文等边界建立领域模型这就是一个收敛的过程。在从业务模型向微服务落地的过程中也就是从战略设计向战术设计的实施过程中我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时系统架构也会同时发生调整并同步建立新的映射关系。DDD 与微服务的关系DDD 是一种架构设计方法微服务是一种架构风格两者从本质上都是为了追求高响应力而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发其核心要义是强调根据业务发展合理划分领域边界持续调整现有架构优化现有代码以保持架构和代码的生命力也就是我们常说的演进式架构。DDD 主要关注从业务领域视角划分领域边界构建通用语言进行高效沟通通过业务抽象建立领域模型维持业务和代码的逻辑一致性。微服务主要关注运行时的进程间通信、容错和故障隔离实现去中心化数据管理和去中心化服务治理关注微服务的独立开发、测试、构建和部署。领域、子域、核心域、通用域和支撑域傻傻分不清DDD 的领域就是这个边界内要解决的业务问题域。领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域每个子域对应一个更小的问题域或更小的业务范围。子域可以根据自身重要性和功能属性划分为三类子域它们分别是核心域、通用域和支撑域。决定产品和公司核心竞争力的子域是核心域它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的但既不包含决定产品和公司核心竞争力的功能也不包含通用功能的子域它就是支撑域。核心域、支撑域和通用域的主要目标是通过领域划分区分不同子域在公司内的不同功能属性和重要性从而公司可对不同子域采取不同的资源投入和建设策略其关注度也会不一样。限界上下文定义领域边界的利器在 DDD 领域建模和系统建设过程中有很多的参与者包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。对同样的领域知识不同的参与角色可能会有不同的理解那大家交流起来就会有障碍怎么办呢因此在 DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。通用语言定义上下文含义限界上下文则定义领域边界以确保每个上下文含义在它特定的边界内都具有唯一的含义领域模型则存在于这个边界之内。在事件风暴过程中通过团队交流达成共识的能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。为了避免同样的概念或语义在不同的上下文环境中产生歧义DDD 在战略设计上提出了“限界上下文”这个概念用来确定语义所在的领域边界。我认为限界上下文的定义就是用来封装通用语言和领域对象提供上下文环境保证在领域之内的一些术语、业务相关对象等通用语言有一个确切的含义没有二义性。这个边界定义了模型的适用范围使团队所有成员能够明确地知道什么应该在模型中实现什么不应该在模型中实现。实体和值对象从领域模型的基础单元看系统设计在 DDD 中有这样一类对象它们拥有唯一标识符且标识符在历经各种状态变更后仍能保持一致。对这些对象而言重要的不是其属性而是其延续性和标识对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。通过对象属性值来识别的对象它将多个相关属性组合为一个概念整体。在 DDD 中用来描述领域的特定方面并且是一个没有标识符的对象叫作值对象。人员实体原本包括姓名、年龄、性别以及人员所在的省、市、县和街道等属性。这样显示地址相关的属性就很零碎了对不对现在我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”这个集合就是值对象了。同样的对象在不同的场景下可能会设计出不同的结果。有些场景中地址会被某一实体引用它只承担描述实体的作用并且它的值只能整体替换这时候你就可以将地址设计为值对象比如收货地址。而在某些业务场景中地址会被经常修改地址是作为一个独立对象存在的这时候它应该设计为实体比如行政区划中的地址信息维护。聚合和聚合根怎样设计聚合领域模型内的实体和值对象就好比个体而能让实体和值对象协同工作的组织就是聚合它用来确保这些领域对象在实现共同的业务逻辑时能保证数据的一致性。聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的聚合是数据修改和持久化的基本单元每一个聚合对应一个仓储实现数据的持久化。聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制而导致聚合、实体之间数据不一致性的问题。如果把聚合比作组织那聚合根就是这个组织的负责人。聚合根也称为根实体它不仅是实体还是聚合的管理者。DDD 领域建模通常采用事件风暴它通常采用用例分析、场景分析和用户旅程分析等方法通过头脑风暴列出所有可能的业务行为和事件然后找出产生这些行为的领域对象并梳理领域对象之间的关系找出聚合根找出与聚合根业务紧密关联的实体和值对象再将聚合根、实体和值对象组合构建聚合。领域事件解耦微服务的关键在事件风暴Event Storming时我们发现除了命令和操作等业务行为以外还有一种非常重要的事件这种事件发生后通常会导致进一步的业务操作在 DDD 中这种事件被称为领域事件。举例来说的话领域事件可以是业务流程的一个步骤比如投保业务缴费完成后触发投保单转保单的动作也可能是定时批处理过程中发生的事件比如批处理生成季缴保费通知单触发发送缴费邮件通知操作或者一个事件发生后触发的后续动作比如密码连续输错三次触发锁定账户的动作。通过领域事件驱动的异步化机制可以推动业务流程和数据在各个不同微服务之间的流转实现微服务的解耦减轻微服务之间服务调用的压力提升用户体验。领域事件处理包括事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。DDD分层架构有效降低层与层之间的依赖DDD 分层架构DDD 分层架构有一个重要的原则每层只能与位于其下方的层发生耦合。微服务架构的演进微服务内服务的演进三层架构向 DDD 分层架构演进DDD 分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分我们可以明确微服务各层的职能划定各领域对象的边界确定各领域对象的协作方式。这种架构既体现了微服务设计和架构演进的需求又很好地融入了领域模型的概念二者无缝结合相信会给你的微服务设计带来不一样的感觉。微服务架构模型几种常见模型的对比和分析整洁架构整洁架构最主要的原则是依赖原则它定义了各层的依赖关系越往里依赖越低代码级别越高越是核心能力。外圆代码依赖只能指向内圆内圆不需要知道外圆的任何情况。六边形架构六边形架构的核心理念是应用是通过端口与外部进行交互的。红圈内的核心业务逻辑应用程序和领域模型与外部资源包括 APP、Web 应用以及数据库资源等完全隔离仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样都是由外向内依赖。三种微服务架构模型的对比和分析这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现而它们身上闪耀的正是以领域模型为中心的设计思想。架构模型通过分层的方式来控制需求变化从外到里对系统的影响从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布灵活多变应用层通过服务组合和编排来实现业务流程的快速适配上线减少传导到领域层的需求使领域层保持长期稳定。项目级微服务项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现服务的组合和编排在应用层实现通过 API 网关为前台应用提供服务实现前后端分离。但项目级的微服务可能会调用其它微服务你看在下面这张图中比如某个项目级微服务 B 调用认证微服务 A完成登录和权限认证。企业级中台微服务我们可以在中台微服务之上增加一层你看下面这张图增加的这一层就位于红色框内它的主要职能就是处理跨中台微服务的服务组合和编排以及微服务之间的协调它还可以完成前端不同渠道应用的适配。如果再将它的业务范围扩大一些我可以将它做成一个面向不同行业和渠道的服务平台。在微服务架构中应用层、领域层和基础层解耦是通过仓储模式采用依赖倒置的设计方法来实现的。在应用设计中我们会同步考虑和基础资源的代码适配那么一旦基础设施资源出现变更比如换数据库就可以屏蔽资源变更对业务代码的影响切断业务逻辑对基础资源的依赖最终降低资源变更对应用的影响。DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心实行分层架构内部核心业务逻辑与外部应用、资源隔离并解耦。中台数字转型后到底应该共享什么中台的关键词共享、联通、融合和创新。联通是前台以及中台之间的联通融合是前台流程和数据的融合并以共享的方式支持前端一线业务的发展和创新。我认为中台首先体现的是一种企业级的能力它提供的是一套企业级的整体解决方案解决小到企业、集团大到生态圈的能力共享、联通和融合问题支持业务和商业模式创新。通过平台联通和数据融合为用户提供一致的体验更敏捷地支撑前台一线业务。数字化转型中台应该共享什么在中台设计和规划时我们需要整体考虑企业内前台、中台以及后台应用的协同实现不同渠道应用的前端页面、流程和服务的共享还有核心业务链路的联通以及前台流程和数据的融合、共享支持业务和商业模式的创新。如何实现前中后台的协同如果把业务中台比作陆军、火箭军和空军等专业军种的话它主要发挥战术专业能力。前台就是作战部队它需要根据前线的战场需求对业务中台的能力进行调度实现能力融合和效率最大化。而数据中台就是信息情报中心和联合作战总指挥部它能够汇集各种数据、完成分析制定战略和战术计划。后台就是后勤部队提供技术支持。前台主要面向客户以及终端销售者实现营销推广以及交易转化中台主要面向运营人员完成运营支撑后台主要面向后台管理人员实现流程审核、内部管理以及后勤支撑比如采购、人力、财务和 OA 等系统。前台通过页面和流程共享实现不同渠道应用之间的前台融合中台通过 API 实现服务共享。而前台、业务中台和数据中台的融合可以实现传统应用与互联网应用的融合从而解决“后端双核心、前端两张皮”的问题。能力复用了前台流程和数据融合了才能更好地支持业务的融合和商业模式的创新。DDD、中台和微服务它们是如何协作的中台是抽象出来的业务模型微服务是业务模型的系统实现DDD 作为方法论可以同时指导中台业务建模和微服务建设三者相辅相成完美结合。中台在企业架构上更多偏向业务模型形成中台的过程实际上也是业务领域不断细分的过程。在这个过程中我们会将同类通用的业务能力进行聚合和业务重构再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。那在中台完成领域建模后我们就需要通过微服务来完成系统建设。此时DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说中台和微服务正是 DDD 实战的最佳场景。DDD、中台和微服务的协作模式如果将企业内整个业务域作为一个问题域的话企业内的所有业务就是一个领域。在进行领域细分时从 DDD 视角来看子域可分为核心域、通用域和支撑域。从中台建设的视角来看业务域细分后的业务中台可分为核心中台和通用中台。从领域功能属性和重要性对照来看通用中台对应 DDD 的通用域和支撑域核心中台对应 DDD 的核心域。从领域的功能范围来看子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系我们就可以用 DDD 来进行中台业务建模了。中台如何建模中台业务抽象的过程就是业务建模的过程对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程对应 DDD 的战术设计。DDD 战略设计包括上述的第一步到第四步主要为业务域分解为中台对中台归类完成领域建模建立中台业务模型。DDD 战术设计是第五步领域模型映射为微服务完成中台建设。欢迎各位读者加入微信群一起学习交流在公众号后台回复“加群”即可~~
