Siam博客

《架构师修炼之道》第八章--建立模型,化繁为简

2022-11-27

建立模型,化繁为简

项目进入了开发阶段,我们发现团队成员描述同一架构元素时使用的词汇各不相同。我们的设计决策表面上取得了一致意见,但大家实际各有各的理解。

我们临时召开涂鸦会议,提炼出通用的元模型,对模型中的概念、元素、关系进行了合理的命名。然后开始重构代码,好在我们的系统刚刚起步。

但在此期间仍然有人不完全理解和赞成架构设计。后面还有必要召开设计研讨会,进一步探讨架构设计方案


开始编写代码前,编写初期;

了解了业务需求,需要提炼模型,清晰概念,决定架构模式,并规范开发词汇和分层、注释等;

推演架构

人脑有限,突破大脑局限性的技巧:

  • 与他人协作
  • 建立抽象概念压缩表示信息(接口或者抽象 只定义行为,不定义细节,压缩信息量)

如果不能分享,再完美的抽象也会失去意义。

分享的办法就是建立抽象的架构模型。模型是对架构的精确秒速,不是草稿

优秀的架构模型有诸多优点

  • 构建设计词汇:我们建立的每个模型都扩展了软件系统的词汇,这些词汇将在日常讨论中使用,融入编写的代码中,影响我们看世界的方式
  • 引导我们关注重要的细节:模型隐藏了部分细节,只展露和关注部分细节
  • 帮助推演质量属性和其他系统特征
  • 展示架构师的构思

设计元模型

定义模型中使用的概念和使用规则,好比是设计的语法 规范思考方式,并且设定讨论架构的词汇

zUNNlQ.png

分离新概念

zUNrkV.png

zUNRX9.png

选择架构模式为基础

(前一章内容介绍了常见的架构模式)

元模型一致性、取好名称

多个部件的模型可能出现了类似职责的组件,如都叫worker,应该进一步修正,引入概念约束

命名应该逐步完善,前期可能概念还未明确 保持空白、凑合

  • 反映功能
  • 反映角色
  • 反映意图
  • 领域抽象:名称超越了单个元素本身,成为一个新的抽象概念。元模型里的新概念就是这样子诞生的
本文链接:
版权声明: 本文由 Siam原创发布,转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
Tags: 架构

扫描二维码,分享此文章