DevOps模型驱动设计
前面我们已经学习了领域模型驱动设计一书，本周我也小试牛刀了一下，从模型驱动设计的角度出发重新设计优化我们的DevOps流程，并且也在部门内部分享了一下。大家听完分享后也纷纷表示觉得模型驱动设计感觉挺清晰的，想要继续学习并尝试去运用到实际工作中。所以本篇文章将把我分享的内容写下来，方便大家在学习和运用中做为参考和比较，能够提出更多的想法一起交流，共同进步。
首先，我们来看一下DevOps需求描述：
按业务范围和领域划分，确认需要开发的需求落到具体哪个业务中心
为业务定义一个code,通过系统注册项目，并自动在GitLab上创建代码仓储（创建项目需全局观看，要符合context划分）
完成开发提交代码，提交tag以release为前缀的，表明此次提交是可发布版本
gitlab webhook触发release版本编译打包镜像，自动累计版本号
dev环境发布版本
发布需选择测试人，测试截至日期
填写发布说明、配置变更、db脚本变更
gitlab自动创建议题事件，assgin给测试人
如项目有自动化单元测试用例，自动执行，并可查看测试报告
测试人确认通过测试后关闭议题，触发自动发布到qas
qas环境测试
用户或业务responser进行UAT测试
完成测试后，标记【测试通过】
prd发布
prd运维每天能收到当天16点前通过UAT测试的待发布新版本统计
运维者点击一键发布或逐个发布
完成发布后通知用户、业务responser已同步更新prd
上面的需求描述因为是从现有DevOps的基础上提出的改进需求，所以看起来已经是比较清晰了，一般如果是第一次的需求，可能会更模糊，更难以理解。但是也没关系，领域模型设计，本来就是需要多次迭代，才能得到更好的更适合更深层次的模型。接下来，我们就要分析需求开始设计了哦。
一、找对象
我们采用对象建模的方式，所以第一步，我们需要做的事情就是找对象，从上面的需求描述中，我们来找找看有哪些和实现DevOps密切相关的对象。从1，2两句描述要注册项目，那么项目这个客观存在的事物就是其中一个对象了。接着，注册了项目就会创建一个代码仓储，第二个对象是仓储；然后开发人员提交代码，每次release提交会打包镜像，所以第三个对象是镜像；有了镜像之后，我们会部署环境，那么部署实例又是一个对象。
二、确定对象关系
对象我们已经找出来了，接下来我们需要确定关系，也许你找出的对象比上面列出的对象要多，这也没关系，你一样可以把它写下来，因为接下来的事情会帮助我们明确，哪些才是我们需要重点关心的对象。这一步我们需要确定对象与对象之间的关系，是一对多、一对一还是多对多等等，以及建立关系的key是什么？对象的关系就如我们生活中的对象关系一样，你有很多个对象也没关系，因为我们非常明确与对象之间的关系，只要关系清楚不乱，就不用担心太多对象会出事。在这里，比如项目与代码仓储的关系是一对一，代码仓储与镜像的关系是一对多，镜像与部署的关系是一对多。我们有同事提出了镜像与环境有关系，不过这个关系就复杂了，一个镜像可以部署到多个环境，一个环境也可以部署很多镜像。所以这里，我们就要砍掉镜像和环境的关系，因为这样复杂的关系，会导致你的模型不清晰，也会导致你的代码实现很乱。因为模型里面对象与对象的关系应尽量简单清晰，我们都很少会建立双向的关系。
三、发现变与不变
在我们确定对象关系之后，非常重要的事情来了，我们需要去发现模型中哪些对象、操作、关系是不变的，哪些是经常变的或者可能变的。不变的事物我们可以用对象、值对象、函数方法等去实现，而变化的事物可以考虑用SERVICE、SPECIFICATION等去实现。然后要降低变与不变之间的耦合关系。在我们的例子中，编译打包的判断规则是可能变化的，环境也可能变化的，不同环境部署的条件也是可能变化的。所以我们设计出来的模型如下图
我们将编译打包的条件做为规则，不同环境的发布条件做为规则。以保证，适应规则的变化，模型的主体对象是不需要任何改动。另外要强调的一点，模型设计必须明确所有的关系和规则，所有的逻辑都可以从模型上表现出来，不要有隐形规则，这样会导致你的代码与模型不一致，那么模型慢慢的就无法体现正真的实现，模型就会失去意义。
上面的模型体现了设计，那么当开发人员需要以及模型开发时，需要更清晰的模型对象直接关系的流程走向，所以可以增加一个时序图，能更加清晰的表述流程走向。
最后，我们可以在从模型的角度出发，用模型语言来阐述一下功能设计：
在系统中注册一个Project （Project根据实际业务发展需要进行注册，注意Project按业务领域划分）
Project注册完成，触发创建一个Repository（Repository对应GitLab上的一个代码库，即注册完成，开发人员即可以拉取Git代码进行开发工作）
开发人员完成开发，提交代码
符合CommitSpecification的代码提交会触发编译打包动作
每一次符合规则的Commit都会生成一个Image，并且每个Image都有一个唯一的版本号
开发人员完成Release代码提交后，在系统中选择对应的Project，点击发布
DEV发布需选择测试人、选择用户、确认配置变更、确认DB脚本变更
DEV Deployment完成，触发生成GitLab测试Issue，Assign To测试人
DEV完成测试后，测试人Close Issue，触发QAS自动发布
QAS Deployment完成，用户执行UAT测试
用户完成UAT测试，在系统中标记测试通过，选择通知运维、最终用户
运维收到待发布PRD统计，确认后执行PRD发布
完成PRD Deployment后，通知最终用户，系统已上线
上面的描述，有很多加粗的部分，就是模型语言的关键术语名词，一定要保证所有的参与人员用户、架构师、开发、测试等，所有人的认识是一致的，这是运用领域模型设计的基础，认知一致，语言一致，最终的交付才能是用户正真需要的。
好了，今天的模型驱动设计就介绍到这里，这里所讲的只是运用了领域模型驱动设计的一小部分知识，还有更多的好用的知识等着我们大家一起去实践~