建立模型,化繁为简
项目进入了开发阶段,我们发现团队成员描述同一架构元素时使用的词汇各不相同。我们的设计决策表面上取得了一致意见,但大家实际各有各的理解。
我们临时召开涂鸦会议,提炼出通用的元模型,对模型中的概念、元素、关系进行了合理的命名。然后开始重构代码,好在我们的系统刚刚起步。
但在此期间仍然有人不完全理解和赞成架构设计。后面还有必要召开设计研讨会,进一步探讨架构设计方案
开始编写代码前,编写初期;
了解了业务需求,需要提炼模型,清晰概念,决定架构模式,并规范开发词汇和分层、注释等;
推演架构
人脑有限,突破大脑局限性的技巧:
- 与他人协作
- 建立抽象概念压缩表示信息(接口或者抽象 只定义行为,不定义细节,压缩信息量)
如果不能分享,再完美的抽象也会失去意义。
分享的办法就是建立抽象的架构模型。模型是对架构的精确秒速,不是草稿
优秀的架构模型有诸多优点
- 构建设计词汇:我们建立的每个模型都扩展了软件系统的词汇,这些词汇将在日常讨论中使用,融入编写的代码中,影响我们看世界的方式
- 引导我们关注重要的细节:模型隐藏了部分细节,只展露和关注部分细节
- 帮助推演质量属性和其他系统特征
- 展示架构师的构思
设计元模型
定义模型中使用的概念和使用规则,好比是设计的语法 规范思考方式,并且设定讨论架构的词汇
分离新概念
选择架构模式为基础
(前一章内容介绍了常见的架构模式)
元模型一致性、取好名称
多个部件的模型可能出现了类似职责的组件,如都叫worker,应该进一步修正,引入概念约束
命名应该逐步完善,前期可能概念还未明确 保持空白、凑合
- 反映功能
- 反映角色
- 反映意图
- 领域抽象:名称超越了单个元素本身,成为一个新的抽象概念。元模型里的新概念就是这样子诞生的
扫描二维码,分享此文章