建立模型，化繁为简

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

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

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

开始编写代码前，编写初期；

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

推演架构

人脑有限，突破大脑局限性的技巧：

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

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

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

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

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

设计元模型

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

分离新概念

选择架构模式为基础

（前一章内容介绍了常见的架构模式）

元模型一致性、取好名称

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

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

• 反映功能
• 反映角色
• 反映意图
• 领域抽象：名称超越了单个元素本身，成为一个新的抽象概念。元模型里的新概念就是这样子诞生的