DDD领域驱动设计内容分享(四十四):如何将DDD应用到基础设施设计?

目录

我所理解的DDD

将DDD应用到基础设施设计的具体做法

小结


前段时间在面试的时候,面试官问到:你是如何将DDD(领域驱动设计)应用到基础设施的?

我很惊讶,终于有人问我这个问题了。

在过去从事基础设施(DevOps、SRE、运维)的5年里,我经常说起DDD是一种思维模式,可以应用到任何的领域,包括基础设施的设计。

但是,从来没有人像这位面试官问起我具体的做法。

为什么没有人问?原因大概是这两个概念通常是不会放在一起的。大多数开发不会深入理解基础设施的设计,而大多数从事基础设施设计的人是不会接触到DDD。而且,开发人员对于DDD的理解,也仅局限于用它开发业务系统。

我就是那少部分人,即做基础设施的设计,又觉得自己懂DDD的人。

说回问题本身。

我所理解的DDD

我首先会向提问的人澄清我所理解的DDD。

为什么要这样呢?很久以前有一次面试,因为我说我擅长DevOps,面试官就认为我不懂GitOps。然后在这个点上他就认为我不适合,不再问我DevOps方面的问题。我只能说没有缘份。

我是这样解释DDD的:

就像开发一个象棋游戏,不论你要开发手机端,还是web端,象棋规则本身都是不变的。这个规则本身就可以理解为“领域”。 其它所有的技术(包括架构)都是具体实现,它们应该由“领域”来驱动设计。

当时的解释与以上的解释大差不差。

将DDD应用到基础设施设计的具体做法

那么该如何将DDD应用到基础设施的设计呢?

DDD的思维方式要求我们首先问:我们要设计的软件的领域(核心)问题是什么?

基础设施的领域问题是什么?我的回答是配置

我认为基础设施的搭建、维护,本质就是配置的设计、部署、维护。

寻找领域(本质)问题的能力是DDD的核心能力。

为了让读者更好理解,我们以一个一个基于云上的虚拟机的分布式系统为例。它的基础设施就包括:vpc、LB、MQ、DB等。

要搭建、维护这一套基础设施。

根据“配置管理是基础设施设计的核心问题”,我首先将基础设施的所有的配置放在清单代码(并不一定是一个文件)中,如下:

vpc:
  # ....
LB:
  # ...
DB:
  # ...
MQ:
  # ...
APP1:
  mq_addr: "{{ MQ.addr }}"
  db_host: "{{ DB.addr }}"
APP2:
  mq_addr: "{{ MQ.addr }}"
  db_host: "{{ DB.addr }}"
  app1_addr: "{{ APP1.addr }}"

从清单中,你看不出它使用何种部署方式、部署顺序。你只知道APP1引用了MQ和DB,APP2会调用APP2这样纯粹的领域知识。

现实通常是多个环境,所以,我一开始就会将不同环境的值从清单上抽离到独立的文件夹中。

第二步,我才会考虑如何部署它们。这时,我通过两个工具实现:

  1. 1. Terraform负责云基础设施;

  2. 2. Ansible负责业务基础设施。

Ansible是可以直接读取我们的YAML格式配置文件。而Terraform代码引用YAML代码,就没有那么方便了。

所以,我决定使用Jsonnet这门配置语言来统一所有的配置,这样不同的配置之间就可以相互引用了。

配置之间的相互引用功能是配置管理的核心功能。

假如某一天,我们需要将云虚拟机的基础设施,迁移到K8s呢?

最上层的清单配置是不需要做什么变更的,因为它和你的具体的基础设施实现是无关的,你只需要更改底层的部分配置。

比如,你需要将Ansible部署工具改成Helm,那么,你需要做的就是写一套通用的Helm chart,然后chart values配置引用上层的APP的配置即可。这时,你会发现,配置的标准化,我们在一开始实现了,而不需要后期返工。

最终我们的基础设施的配置的架构,可以简化成下图:

小结

我是如何将DDD应用到基础设施的:

  1. 1. 基于自己对基础设施的理解,将“配置管理”定义为这个领域的核心问题;

  2. 2. 分析配置管理的所带来的具体问题;这一步通常由领域专家来做。本文我是直接略过这一环节;

  3. 3. 根据第二步,决定使用代码去管理配置;

  4. 4. 根据基础设施的上下文(是否使用云,是否云原生)选择工具,读取配置,然后实现部署与维护。

不论你是否赞同使用基础设施即代码,我的基础设施的设计都是由配置管理(领域)这个问题驱动。

比如在实现流水线时,将构建工具逻辑与流水线流程逻辑解耦、在设计 版本号时,将构建工具本身的版本号与流水线流程生成的版本号分离。

如果你不熟悉DevOps也没有关系,你只需要知道DDD贯穿着整个系统设计的每一个细节。

现在市场上把DDD吹得很高大上,似乎只有在架构上做DDD,才叫DDD。又或者非得和微服务关联在一起,才叫DDD。

其实不然,DDD的原意是领域驱动设计。只要你是使用领域知识来驱动你的设计,这个设计可以是方法级别的设计、类级别的设计、前端UI的设计等一切设计,你都可以叫DDD。

也许,这样的话听起来就像“色即是空,空即是色”一样让人不知所云。

没办法,10年了,我也没有找到非常好的让人一下就懂这种思维方式的方法。

如果非得要我介绍一下DDD的思维是什么,我觉得就是:不停地问问题是什么,解决方案是什么。然后优先从问题域着手设计。在确定问题域设计得差不多了,才开始实现解决方案。

这里要提个问,如果拿到一个需求时,先设计MySQL的表结构,再根据表结构导出类。这样的方式符合DDD的思维方式吗?如果不符合,与DDD的思维方式有什么区别?

  • 32
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

之乎者也·

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值