领域驱动设计(DDD)
2023-12-28 16:42:04 37 举报AI智能生成
领域驱动设计（Domain-Driven Design，简称DDD）是一种软件开发方法，它关注于核心领域和领域逻辑的理解与实现。通过将复杂的业务问题划分为独立的子领域，并建立领域模型来描述这些子领域的规则和关系，DDD能够帮助开发团队更好地理解业务需求，提高软件的可维护性和可扩展性。在DDD中，领域专家与开发人员紧密合作，共同挖掘领域知识，形成一致的语言和概念模型。同时，DDD强调分层架构、模块化设计和依赖倒置原则，以实现高度可测试性和可重用的代码。总之，领域驱动设计是一种以业务为中心、注重领域知识和实践的开发方法，有助于提高软件质量和开发效率。
作者其他创作
大纲/内容
产生背景
希望软件的设计能正确的反映需求模型和软件架构方便扩展，做出正确的、有竞争力的业务整合决策。期望微服务能容易扩展、富有弹性
解决微服务如何设计、拆分、边界等问题，避免因为过度拆分导致部署维护通信困难，也要避免拆分粒度过大导致一些遗漏的业务被分散到各个服务中，并不断的重复等问题。
DDD不是一种架构，而是一种划分业务领域范围的方法论。利用DDD的思路进行业务梳理可以很好的划分服务边界，从而实现微服务内部和外部的“高内聚，低耦合”。具体做法为将问题拆分成一个个域，试图分离技术实现的复杂性，将问题简单化，帮助我们设计出清晰的领域和边界，很好的实现技术架构的演进。
战略设计从业务视角出发，建立业务领域模型，划分领域边界，建立通用的语言和界限上下文，界限上下文可以作为微服务设计的参考边界
战术设计从技术视角出发，侧重于领域模型的技术实现，完成软件的开发和落地，包括聚合根、实体、值对象、领域服务、应用服务、资源库等
战略设计
步骤1：使用DDD进行业务建模，从业务中获取抽象的模型，并根据模型的关系划分界限上下文；2、检验模型是否得到了合适的抽象，并能反应系统设计和响应业务的变化；3、从DDD的界限上下文往微服务转化，得到系统架构、API列表、集成等方式进行输出
如何抽象？找到一组概念相近、高度内聚并能识别清晰的业务边界的业务模型，成为界限上下文。如何找到上下文的边界？通过领域事件风暴的形式，协调业务需求提出者和技术实施者完成建模，把系统状态做出改变的事件作为关键点为触发条件，提取能反映系统运作的业务模型，再进一步划分出界限上下文，就可以当做逻辑上的微服务
如何评审领域模型或界限？从微服务的目的出发，降低耦合且容易扩展。
原则1：边界之间互相依赖越少越好，上游不应知道下游的信息
原则2：使用潜在的业务进行适配，如果能再一定程度上响应业务上的变化，
则可以证明DDD指导的微服务可以在相当一段时间内足以支撑应用开发
则可以证明DDD指导的微服务可以在相当一段时间内足以支撑应用开发
原则3：从抽象程度、成本、复用性三个因素中获取平衡
如何完成界限到微服务的转化？
1、设计微服务之间的依赖关系，依赖代表组件之间的调用，原则应保证上游系统不知道下游系统的信息
2、设计微服务之间的集成关系，可采用RPC（如dubbo）、消息异步处理、restful 的http协议继承集成
战术设计
战略设计提供了一种高层视野来审视我们的系统，而战术设计则是将战略设计具体化和细节化的手段。战术设计关注的是技术层面的实施。
1、封装行为饱满的领域对象：传统的对象充斥着大量的getter、setter方法，指封装了属性而弱化了行为的对象，称为贫血模型。我们需要改变思路，将领域对象不仅仅充当数据的容器，更是讨论领域对象能提供哪些行为，即OOP思想
2、设计实体和值对象：实体代表具有生命周期并且在生命周期内会发生改变的对象；而值对象具有创建即一致的特性，不会发生改变，可以代表简单相同属性的归纳，提升内聚性；而实体存在唯一标记
3、聚合：聚合包含一个或多个实体和值对象，是持久化的基本单位，和资源库具有一一对应的关系。设计原则为，聚合代表了一个事务提交的基本单位。（若需要跨服务进行通知，则应当采用领域事件的方式进行，数据的一致性变成最终一致性即可）
4、领域服务：将无法归纳到领域对象中的行为，即可当做领域服务。如密码加密等
5、资源库：用于保存和获取聚合对象，具有明显的领域特征。一般可分为聚合资源库、持久化资源库
战略实践工作坊
准备阶段
参与人员对工作坊的开展背景、需要解决的问题、产出的目标理解一致
价值定位或核心差异化竞争优势已澄清，能够通过量化的方式进行定义和描述，并达成一致
参与人员必须接受过相关培训，有能力共同清晰描述业务流程，如有缺失信息需要及时补充领域专家
产品、项目负责人、领域专家、技术专家必须全程参与，并对结果负责
流程概述
战略设计：业务驱动，忽略技术实现细节，为系统架构设计提供业务边界对齐、弹性边界对齐、战略投资优先级的信息输入
战术设计：基于战略设计的信息输出，进行进一步的抽象设计，作为战略设计和技术实现的过度阶段，为技术实现提供基于抽象模型和业务服务划分的输入
技术设计：根据战略和战术设计的信息输出，进行技术实现相关的设计。例如：技术性组件补全、技术选型、业务API详细设计、分层架构设计、领域模型类的设计、数据库设计、策略制定等等
事件风暴
是一种战略设计，是DDD协作设计的方法，基于业务流程，考虑系统实现为视角，通过一次只关注一个维度的分层抽象方式，将现实业务流程进行抽象并转化为系统实现的业务逻辑。设计过程中，忽略具体的技术实现，做到抽象与实现的细节解耦，满足领域驱动而部署技术驱动的需求
步骤
识别领域事件
领域事件是领域专家关心的、业务上真实发生的事情，这些事对系统会产生重要的影响，如果没有这些事情的发生，整个业务逻辑和系统实现将不能成立。可进行事件溯源、设计成专门的事件类
影响
对内：产生了某种数据；触发了某种流程；状态发生了某种变化；对外：发送了某些消息
规则：对分支条件或复杂业务规则的抽象，可降低复杂度聚焦主要的业务流程，未来的实现可能是一些分支条件、设计模式等
步骤：1、明确场景；2、确定起始和结束事件；3、以时间线的方式梳理事件，确定先后顺序或并行关系；4、使用规则抽象分支条件和细节，降低分支复杂度；5、逆向检查事件流的合理性
要求：原子性，不可再拆分
识别决策命令
是领域事件的触发动作，代表业务流程上重要的业务决策，技术实现的时候通过领域对象的方法来实现
实施者
实施者是决策命令的发起者，它可以是：角色或设备、外部系统、定时任务、前置事件
识别领域名词
是业务上下文中存在的领域概念，包括：现实中的事物、可抽象的业务概念、决策命令或领域事件中均出现了的名词
领域名称可作为构建聚合、实体、值对象的参考
界限上下文
是业务的边界，在边界内交流的业务概念不会产生理解上的歧义，是统一语言的重要保证
步骤
将事件风暴或外部系统提取得到的领域名词，保证不重复后归类放置
澄清语言的二义性（即在不同的上下文中相同名词所代表的概念也会有区别）；考虑业务的相关性；考虑概念的相关性
根据相关性进行领域名词的分组，并使用“XX”上下文的形式进行抽象和命名
梳理上下文之间的关系：分析依赖关系和识别依赖矛盾，被依赖的一方无需依赖者的存在
注意：界限上下文具备概念上的独立性，界限内的子概念的解释和目的都不应超出它承载的上下文边界
根据弹性边界划分服务
弹性边界是云原生的重要视角，具备同样的伸缩原因和一致性边界，能通过复制实例的方式实现弹性需求，存在独立部署满足业务需求的可能
云原生
微服务：应用之间通过restful-api方式进行通讯、可被独立部署、更新、重启
devOps：自动发布、快速部署、开发运维协调合作
持续集成/持续交付(CI/CD)：快速交互、频繁发布、快速响应、降低发布风险
容器化：微服务的最佳载体
采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps
支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率
支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率
决定我们的部署方式、运行和开发服务，从而影响系统内业务组件的划分，考虑开发、运维的成本而采用的最终方案
划分问题子域
子域是对问题域的澄清和划分，也是资源投入优先级的重要参考
类型
核心域：是当前产品核心差异化的竞争力，是整个业务盈利的来源和基石，如果核心域不存在，整个业务都不能运作。需要投入最优势的资源进行合理的设计
支撑域：解决核心域运作支撑，具备一定的定制化需求，比较少有现成的解决方案，需要专门团队进行定制开发
通用域：业界常见有通用的解决方案，或简单的购买或修改即可直接使用
依据：每个问题子域都具有解决独立业务价值的效果，将解决同一个问题的界限上下文划分到一起
注意：界限上下文是业务是识别和语言的统一；子域是问题的澄清和优先级排序。一个子域可以包含多个界限上下文，但一个界限上下文不能跨过子域
战术实践工作坊
领域建模
领域模型是对业务高度的抽象，利用抽象模型作为业务和系统实现的核心联系，封装承载了全部的业务逻辑，并保持“高内聚、低耦合”的原则
抽象模型类型
聚合根：是一种实体，是聚合的根节点，可包含多个实体，遵循最小事务提交原则
实体：是聚合的主干，包含状态和唯一标识，具有生命周期
值对象：实体业务的附加概念，具有不变性（也有称为读模型），是一组概念的封装。正确的使用能避免过多的属性拍平到实体，导致缺失必要的抽象
步骤
1、选择并聚焦一个界限上下文，将领域名词与其所有的决策命令、领域事件划在一起
2、基于聚合、实体、值对象的定义和识别原则，将领域名词按其所具备的业务概念联系起来，并作为适合的类型
3、联线聚合内的实体，虚线代表对另一个聚合的引用
4、用潜在的业务需求来检验模型的业务响应能力，是否可简单修改即可匹配新的业务需求
重构服务划分：基于已有的产出，再次检查设计的合理性，调整各项产出物，领域名词全部替换成聚合名称
服务接口能力识别
指业务服务以接口的形式公开提供给消费方的业务能力，能够为未来的API技术实现提供参考输入
步骤
1、识别对外暴露的决策命令，可作为API的名称
2、补充其它有价值的API
3、按照界限上下文、聚合、接口能力的分类，列出API清单
0 条评论
下一页
