乐趣区

关于c#:MASA-Framework-DDD设计1

jiezi

DDD

畛域驱动设计是一个无关软件开发的 方法论，它提出基于畛域开发的开发模式，基于 DDD 实践，咱们能够设计出高质量的软件模型。

它围绕业务概念构建畛域模型来管制业务的复杂度，解决软件难以了解和演变的问题。

微服务

微服务是一种 架构格调，通过过程间通信、容错和故障隔离等形式，实现去中心化的服务治理。

DDD 与微服务

它们都是高内聚、低耦合，从业务视角拆散复杂度，进步响应能力。

高内聚：把相干的业务汇集在一起

低耦合：把关联性较低的拆分为独立的服务

应用 DDD 搭建微服务咱们将取得以下劣势：

  • 设计清晰，标准
  • 基于畛域模型，有利于畛域常识的传递和传承
  • 帮忙团队建设良好的沟通
  • 帮助零碎架构的演进
  • 进步团队的设计能力（面向对象，架构）

设计

畛域设计波及技术与业务，如何让它们合作起来呢？

策略设计（业务）

畛域、子域、限界上下文

  • 将畛域拆分成子域，并划分外围子域、撑持子域和通用子域
  • 以子域开展事件风暴，依据上下文语义划分限界上下文，建设通用语言，实现领域建模
  • 领域建模将作为能力核心布局的重要依据
  • 实现能力核心地图和优先级后，作为微服务设计的输出实现战术设计

战术设计(技术)

聚合、聚合根、实体、值对象、畛域服务等

  • 依照畛域模型实现微服务设计和落地

  • 建设聚合、聚合根、实体、值对象、畛域服务等对象之间的依赖关系，以代码对象的模式映射到服务中，采纳分层架构实现微服务设计和落地

    分层架构能够采纳 Clean Architecture

DDD 实际过程

咱们将通过 DDD + Clean Architecture 实现业务与技术的残缺落地

对立语言（策略设计）

对立：

  • 畛域模型术语
  • DDD 模式名称

技术：

  • 技术设计术语
  • 技术术语
  • 技术设计模式

业务：

  • 畛域模型术语
  • DDD 模式名称
  • 业务术语
  • 设计无关的业务术语

事件风暴（策略设计）

Event Storming 是一种领域建模的实际，能够让畛域相干人员疾速了解业务模型

残缺流程包含如对立语言、提出畛域事件、规定、命令、读模型、角色、划分子域、票选、补充商机与价值等，

接下来咱们先精简一点步骤

流动筹备

人：业务人员，领域专家，技术人员，架构师，测试等

看板：能够将事件流可视化的白板或者画图工具等

黑白贴纸：填写事件，命令等

业务场景

规定业务场景，上面我以一个电商我的项目为例

事件风暴后果

命令风暴后果

寻找聚合

聚合：一组相干畛域模型的汇合，尽量保障封装业务的不变性，确保关联关系严密的畛域模型内聚

  1. 按事件程序顺次剖析三个问题

    • 事件扭转的畛域模型是什么
    • 畛域模型是否能够独立拜访，是就是聚合
    • 不能独立拜访，须要通过哪个畛域模型（聚合）来拜访，将其放到对应聚合内
  2. 命令贴在聚合右边代表输出，事件贴到聚合左边代表输入
  3. 测验是否合乎聚合规定，不匹配的从新调整聚合

聚合后果

寻找聚合过程中可能会因为业务连接产生新的输出命令，以虚线示意

划分限界上下文

限界上下文：某个场景或环境下的业务边界

  1. 基于聚合和畛域模型，判断它们要解决的业务问题，如果是同一个问题则放到一个限界上下文中，否则就拆分
  2. 如果一个聚合同时解决多个问题，则须要对聚合进行拆分，将拆分后的聚合划分到不同的限界上下文
  3. 解决的业务问题大小（变动起因，外在逻辑等）需与领域专家共同完成

限界上下文后果

界线上下文映射

当上下文很多的时候，不同的团队负责不同的上下文，为了保障无效的工作能够定义不同的上下文之间的关系来创立一个所有模型上下文的全局视图。两个上下文之间是有方向的，上游(U 或 Upstream)，上游(D 或 Downstream)

界线上下文映射后果

子域

一个业务畛域或子域是一个业务范围。一个业务畛域或子域能够包含多个业务能力，一个业务能力对应一个服务。

外围子域指业务胜利的次要促成因素，是企业的外围竞争力。

通用子域被整个业务零碎应用。

撑持子域是实现业务的必要能力，但不是胜利的因素。

除了下面限界上下文后果中标注的子域外，还能够扩大出财务，市场，洽购等子域

畛域对象关系（战术设计）

合成聚合，提取该聚合蕴含的畛域对象

  • 畛域对象的业务不变性
  • 畛域对象具备统一的生命周期

定义实体与值对象（战术设计）

实体：存在唯一性标识，实体间是否相等的判断根据也是惟一标识

值对象：示意属性的不变值

以订单聚合为例：

  • 订单聚合蕴含订单实体，订单行实体
  • 订单实体蕴含收货地址值对象

架构设计

咱们简略的把架构设计看作是三个层面：

  • 业务架构：依据业务需要设计业务模块及其关系

    DDD 的领域建模其实就曾经帮助咱们做了业务架构和零碎架构

  • 零碎架构：设计零碎与子系统的模块及其关系

    在 DDD 中业务架构是能够间接映射到零碎架构上的

    业务变动会演变为零碎架构变动，影响到技术架构变动

  • 技术架构：设计技术和框架细节

    技术架构（微服务）则解决子系统之间的解耦，去中心化的服务治理和数据治理

Clean Architecture

寻找聚合时咱们提到过输出和输入。而 Clean Architecture 与 DDD 汇合后就非常适合作为采纳 DDD 方法论的架构落地领导

为了更好的落地读模型设计（查问业务比拟往往占八成以上），搭配 CQRS 可能是个不错的抉择。

CQRS 劣势在于职责拆散，进步零碎性能、可扩展性、安全性等。也能够从数据驱动转为事件驱动。

要理解 CQRS 能够看第二篇 MASA Framework – EventBus 设计

示例能够参考 MASA EShop 源码：https://github.com/masalabs/M…

除了 DDD 以外，咱们还提供了 EventBus、Dapr、CQRS 等多种实现形式

老零碎演进

绞杀者模式

在现有零碎外围将新性能用新的形式构建为新的服务的策略，通过将新性能做成微服务形式，而不是间接批改原有零碎，逐渐的实现对老零碎替换。采纳这种策略，随着工夫的推移，新的服务就会逐步“绞杀”老的零碎。对于那些规模很大而又难以对现有架构进行批改的遗留零碎，举荐采纳绞杀者模式。

毛病：可能须要一段时间同时保护两个或以上的我的项目

修理模式

修理者模式就如修房或修路一样，将老旧待修理的局部进行隔离，用新的形式对其进行独自修复。修复的同时，需保障与其余局部仍能协同性能。从这种思路登程，修理者模式更多体现为一种重构技术。

DDD 实际流程

总结

DDD 尽管须要肯定的学习老本，但把握后既能够设计简单的工程，也能够适当的缩减流程，在小型我的项目中间接以畛域和聚合疾速形象畛域模型，配合本人习惯的技术手段（如论是 DB First 还是 Code First）来增强对系统设计的掌控力。

第一篇次要解说 DDD 在团队中如何落地，而第二篇则是站在开发的角度如何落地。

学以致用，学无止境。

参考：

AWS 畛域驱动设计最佳实际

畛域驱动设计在互联网业务开发中的实际：https://tech.meituan.com/2017…

开源地址

MASA.BuildingBlocks：https://github.com/masastack/…

MASA.Contrib：https://github.com/masastack/…

MASA.Utils：https://github.com/masastack/…

MASA.EShop：https://github.com/masalabs/M…

MASA.Blazor：https://github.com/BlazorComp…

如果你对咱们的 MASA Framework 感兴趣，无论是代码奉献、应用、提 Issue，欢送分割咱们

退出移动版