易坊好文馆

  1. 首页 > 玩科技 >

领域|如何成为云原生时代的卓越架构师

业务 软件 领域 技术 服务化 方法 本质 模型 云原生 卓越 架构师 复杂性

简介： “软件开发需要面对本质困难和附属困难 。 云原生、DevOps大幅降低了附属困难 ， 使得架构师可以全力聚焦于业务复杂性 ， 而DDD恰是管理业务复杂性的有效方法 。 ”
本文作者：张刚 ， 阿里云云效资深技术专家 ， ALPD方法学核心成员 。
软件开发的本质困难 1986年 ， 软件工程巨匠Frederick Brooks撰写了一篇著名的论文《没有银弹》 。 他在文章的开篇写道：
在未来的10年以内 ， 不存在任何单一的方法和技术 ， 能够10倍以上的提高软件开发的生产力 。
这个论断在当时就引发了巨大的争议 。 至今 ， 《没有银弹》仍然是一个被经常拿出来讨论的话题 。 不过 ， 这篇论文的真正价值远不限于此 ， 继续读下去 ， 就会发现 ，。 停留在是否存在10倍以上生产率的讨论是不够的 。 真正值得关心的 ， 是Brooks对原因的论断 。 我把其中的重要观点概括如下：
软件开发的困难有两类 ， 一类是本质（Essential）困难 ， 一类是附属性（Accidental）困难 。
本质困难是和软件的本质紧密联系在一起的 ， 所以这类困难无法通过工具或者语言等加以解决 。 例如 ， 软件解决的问题是现实世界的问题 ， 如果现实世界的问题本来就是复杂的 ， 那么无论任何工具 ， 都不可能消除这种复杂性 。
附属性困难是和我们采取的工具或者方法相关的 。 例如 ， 软件需要被通过某种语言实现 ， 软件需要被编译、被部署 ， 软件可能被实现为缺陷 ， 这些都和具体的实现方法相关 。 这一类困难 ， 可以通过工具、方法和技术的提升得以改善 。
本质困难包括软件的复杂性 ， 不可见性、可变更性和符合性（指软件开发还需要遵从诸如法律法规、外部系统等不受主观意志决定的因素）
作为一名在软件开发行业工作了20年的架构师 ， 《没有银弹》关于本质困难和附属性困难的论述给了我巨大启发 。
多年以来 ， 我一直都把“管理本质困难、消除附属困难”作为软件开发活动的座右铭 。 特别有意思的是 ， 最近我发现 ， 作为一个主要工作在业务系统上的架构师 ， 在云原生渐成趋势的时候 ， 架构师的职责已然发生了改变 。 而这个变化 ， 恰恰和“管理本质困难、消除附属困难”密切相关 。
业务架构当然也是架构师的重要职责 。 业务和技术已经深度融合 ， 业务对响应速度的要求和开发质量的要求越来越高 ， 同时在云原生时代 ， 服务化几乎成为必然选择 。 而无论是业务响应能力、开发质量和服务化 ， 都和业务规划能力密切相关 。 这不就是最重要的“管理本质困难”的方面嘛！
领域驱动设计 ， 虽然Eric Evans的同名书籍写于2004年 ， 多年以来 ， 在技术社区也有较大影响 。 但是为什么最近几年热度突然大幅上升 ， 变得特别受关注呢？这是因为 ， 我们的业务终于越变越复杂 ， 到了如果没有恰当的方法 ， 就不能很好的管理的地步——这也恰恰暗合了DDD一书的副标题“软件核心复杂性应对之道“ 。 微服务和云原生在服务方面的划分等 ， 也是关键的助推因素 。
成为云原生时代的架构师 在今天的业务环境下 ， 能更好地利用好云原生基础设施 ， 更好地进行业务规划、高效高质地分析和管理领域模型 ， 用领域模型指导架构设计和开发实践 ， 是云原生时代架构师的重要技能 。
这次云效和阿里云开发者学院联合推出的《ALPD云架构师系列——领域驱动设计》课程也正是围绕着这个主题展开 。
ALPD全称Advanced Lean product development ， 它是阿里云云效团队提出的云原生时代的研发新范式 ， 它整合了技术、工程、协作、创新4类实践 ， 并提供高效解决方案 。

领域|如何成为云原生时代的卓越架构师
文章图片


领域|如何成为云原生时代的卓越架构师
文章图片

上面2幅图分别是ALPD方法和支撑体系图 ， 我们希望ALPD及其解决方案可以帮助企业和开发者 ， 实现10倍效能提升——10倍的响应速度 ， 10倍的过程质量 ， 10倍的有效价值交付 。
在本次课程中 ， 我们将为大家带来 ALPD方法体系中的领域驱动的架构和实践 部分的内容 。
能通过这一次的对外整理 ， 将知识和经验分享给社区开发者小伙伴 ， 也是非常开心的事情 。
ALPD云架构师系列课程——DDD高手进阶 在课程整理中 ， 我们把课程分成了如下章节：
01|领域模型的本质是业务认知
02|案例分析：高质量领域模型提升业务灵活性
03|高质量领域模型源自持续演进
04|案例分析：梳理业务概念 ， 发现领域模型
05|从模型到代码：领域驱动设计的构造块
06|聚合：保证业务完整性的单元
07|领域驱动设计的分层模型和代码组织
08|核心域、通用域和支撑域
09|基于业务能力和业务场景拆分子域
10|守护领域边界 ， 构建自治服务
11|限界上下文映射的模式
12|使用微服务构建领域资产
其中每讲都保持了15分钟左右的篇幅 ， 以聚焦于一个比较内聚的主题 。
1-4讲 ， 讨论领域模型的一个基础概念 ， 包括什么是领域模型？为什么要关心领域模型?如何进行基本的领域建模？
5-7讲 ， 主要关心领域模型为中心的软件实现 ， 具体对应于领域驱动设计的战术模式 ， 例如实体对象、值对象 ， 领域服务、领域事件构造块及聚合、资源库和工厂这些跟业务完整性密切相关的部分 。
8-12讲 ， 关心领域模型为中心的架构设计 ， 具体对应于领域驱动设计的战略模式 ， 比如说子域、限界上下文、限界上下文映射等方面的话题 。 最后的12讲 ， 我们把微服务跟领域资产之间的关系也做了讨论 ， 微服务是当前一个重要话题 ， 如果对领域驱动设计关注不足 ， 也会影响到微服务和云原生的实施 。
在整个课程中 ， 没有晦涩难懂的概念 ， 我更希望能通过简明的案例让学员轻松理解领域驱动设计的核心思想和关键实践 。 希望你也能通过学习这个课程 ， 可以从本质出发 ， 更好地理解DDD并付诸实际项目实施 。
当然 ， 领域建模和领域驱动设计仍然是需要长期刻意练习的技能 ， 课程中的内容也还只是抛砖引玉 ， 在后续的实际工作中希望你能持续应用和提升 ， 不断精进 ， 成为云原生时代的卓越架构师！
【领域|如何成为云原生时代的卓越架构师】本文为阿里云原创内容 ， 未经允许不得转载 。

    推荐阅读


    上一篇：领域|为什么你应该关心领域模型？

    下一篇：仪器|AHAM标准的空气过滤器性能测试舱