确认架构规划完整性的八个关注点

简介: 【1月更文挑战第19天】

通过架构规划中的确认环节来控制风险与保障交付,就是在这个环节的核心关注点。具体而言,规划确认包含八个部分。

1、定稿架构规划文档

在定稿的过程中,你可能会和不同团队、企业外部专家产生诸多交互。这个时候你就需要与执行者确定规划内容。因为之前的收集主要是作为规划的输入,而不是执行者的承诺。所以你就需要把输入转成一个可行且有约束力的规划。


架构师的角色有点像律师。除了最小化交付风险外,还要确保所有参与者有能力且有意愿履行他们的责任。怎么确保呢?答案是为参与者拟定一个合同。


这是一个用来提升交付确定性的切实有效的工具。规划确认过程中的每一个交付项,比如用例文档、必保任务、领域模型、API 设计、消息和数据流、整体交付节奏和完整性验证等,都指向同一个目的,即提升交付的确定性。这也是架构规划的实质。


2、组织用例文档

用例文档是关于交付内容的最简洁的描述。它的作用是描述架构活动中某个团队或者小组要为某个用户角色,在某个场景中,创造出某种价值。


需要格外注意的是,无论是写用例,还是用一张图来表示用例,都需要避免堆积。在一个架构活动中,不论是十个人还是上百人参与,最顶层的用例最多也不能超过十个。


对用例的描述除了要尽量简洁外,还要将其整理成一个文档。这样的话,几乎所有人都能通过阅读这些用例来获得更为宏观的视角。而具体的每个场景的细节描述和需求文档,可以通过链接记录到另外的文档中。


3、确认必保任务的交付节奏

在架构规划的环节,我们还需要重新梳理一遍在任务边界划分中,做出来的具体的任务描述。并且要确保这些必保任务录入到了 Jira 之类工具中。借助这个工具,我们需要收集所有必保任务,并确认任务分配和交付排期。最终,我们需要通过这个工具来跟踪所有必保任务的交付情况。 需要注意的是,这些必保任务也要和用例形成关联关系。


4、确认领域模型

同样,在这个阶段之前,你准备的领域模型也是一组输入。那么在规划确认这个环节,你就需要完成定稿。这是一个统一语义的过程,整个架构活动只能有一个问题域模型。虽然不同的执行者可以帮你梳理领域模型,但是你必须把整个领域模型整理到同一个语义环境中。这是对于架构活动中要解决的问题的准确描述。另外,你必须让最终的执行者来确认领域模型。因为之前帮你起草领域模型的,不一定是最终的执行者。


5、确认 API

有了用例文档、必保任务和领域模型,接下来就可以请各个团队完成 API 设计了。如果架构活动中主要使用的是 RESTful 框架,那么 Swagger 就是一个非常好的选项。


相比 Wiki,Swagger 的优点是:

  1. 有约束性。我们刚才把架构师在这个环节的角色看作律师,那么我们就要看看执行方能提供什么样的服务。
  2. 易读易用。对于大多数程序员来说,读代码要比读文档更便宜。
  3. 有 Copyright 和 Ownership。研发人员非常在意自己的口碑,一般比较资深的研发都会在 API 的定义上面下很大的功夫。不像 Wiki,很容易变成一个 Group 文档。
  4. 有投入度。连 Swagger 都不想写或者写不出来的人,估计你未来也很难撬得动他,甚至也用不上这样的人。所以在 Swagger 上的投入,能让你提早发现资源和能力上的问题。
  5. 规范性好,很容易在团队中标准化掉。
  6. 可测试性好,容易验证其完整性。
  7. 长期回报大。仅架构活动本身,对定义者本人的价值就很大,可以帮助他想清楚问题。而对于依赖这个 API 的人来说,价值就更大了。他可以及早做 Mock 测试,及早给出反馈意见,避免在很晚的时候才发现集成问题。长期来看,还可以让整个团队形成好的设计习惯,从而提升整体的 API 质量。这是个典型的有复利的编程模式。


6、确认消息和数据流

在确认好 API 之后,接下来就要去确认消息和数据的流转了。也就是某个角色在某个时间能为某个使用方提供某些消息和数据。消息,是除了 API 调用外服务间最常见的通讯机制,甚至可以说是过分常见了。事实上我一直在怀疑,过去大多数利用消息解耦的场景,在今天的计算能力之下,到底还是不是一个好的设计模式。


这是个常规工作,没太大的技术难度,难的是保障资源投入、模型质量和数据质量。所以如果在这个阶段就及早规划,会省去后续很多麻烦。


7、确认强依赖任务的交付节奏

虽然通过依赖解耦和 Swagger 的应用,能让你并行处理一些工作。但是真正的集成,以及对异常情况的处理,还是需要完成强依赖任务后才能进行。所以确认强依赖任务的交付节奏,是你这个架构师、项目经理和执行者在各个用例层级上都要进行的任务。


8、确认整个架构规划的完整性

整个架构规划的完整性确认,需要测试和相关团队核心人员的介入,从而确保核心场景的核心用例能被现有的功能所覆盖。同时也要确认 API、消息、数据是完整和兼容的,整体集成风险是可控的。在这个环节,一般不太关注边界条件的梳理,主要是担心会把过多的注意力分散在较小,甚至是比较难的异常情况梳理上,而在核心场景和强依赖任务的梳理上投入得不够。


规划确认环节的王道,就是通过精细规划来控制风险,保障全面启动前交付风险的最小化。


相关文章
|
8月前
|
机器学习/深度学习 算法
【5分钟paper】基于近似动态规划的学习、规划和反应的集成架构
【5分钟paper】基于近似动态规划的学习、规划和反应的集成架构
|
9月前
|
架构师 前端开发 安全
|
11月前
|
消息中间件 Cloud Native RocketMQ
带你读《企业级云原生白皮书项目实战》——6.3.4 未来规划
带你读《企业级云原生白皮书项目实战》——6.3.4 未来规划
|
11月前
|
架构师
「业务架构」基于EA路线图的业务能力规划
「业务架构」基于EA路线图的业务能力规划
|
11月前
|
机器学习/深度学习 Kubernetes API
「容器架构」 K8s 集群如何规划工作节点的大小?
「容器架构」 K8s 集群如何规划工作节点的大小?
|
存储 缓存 NoSQL
【分布式技术专题】「架构实践于案例分析」盘点高并发场景的技术设计方案和规划
【分布式技术专题】「架构实践于案例分析」盘点高并发场景的技术设计方案和规划
193 0
【分布式技术专题】「架构实践于案例分析」盘点高并发场景的技术设计方案和规划
|
存储 Kubernetes 云计算
如何规划多云架构
组织规划有效的多云架构不仅仅是将另一个云平台添加到运营环境中并每天调用。组织还应该制定多云的详细实施计划,以尽量减少与多云环境相关的挑战。根据定义多云的精确程度,组织的多云策略也可以集中在混合架构上,该混合架构将内部部署环境或私有云与公共云混合在一起。
439 0
|
存储 JSON 分布式计算
阿里云大数据平台 -时序数据集成架构与存储规划
阿里云大数据平台集成时序数据的架构与存储规划
1103 0
阿里云大数据平台 -时序数据集成架构与存储规划