从程序员往架构师转型的路上，蔡学镛老师总结的“四维架构设计方法论”对我颇有帮助，让我对架构设计有了更立体化、系统化的认知，现将学习心得分享出来供需要的小伙伴参考。
成都创新互联拥有一支富有激情的企业网站制作团队，在互联网网站建设行业深耕十多年，专业且经验丰富。十多年网站优化营销经验，我们已为上1000+中小企业提供了成都网站建设、
成都做网站解决方案，按需网站制作，设计满意，售后服务无忧。所有客户皆提供一年
免费网站维护!
这套方法论通过空间（
X
、
Y
、
Z
）三个维度及时间
T
维度将问题域解构成可以轻松应对的小方块，分而治之。同时，空间（
X
、
Y
、
Z
）三个维度联动，专门为单个维度解决不了的问题提供解决方案。时间
T
维度将问题分解到一个时间范围内，分步骤按节奏逐一解决。多维度、立体化、分层次、动态演进，这是我对这套方法论特点的总结。
接下来，让我们进入这个四维的架构时空一探究竟！
图
1
四维座标系统
前后端维度（
X1 … X7
）
前后端维度被分解为交互、业务、领域、资源四大层，其中业务可以细分为应用
X2
、框架
X3
，领域可以细分为服务
X4
、核心
X5
，资源也可以细分为代理
X6
、数据
X7
，共分为七个层次。服务
X4
可以实现
API
，如果公开，就是开放接口，调用服务层的接口，通常需要授权。代理
X6
可以实现
SPI
，隔离耦合，避免核心
X5
依赖特定的外部系统或数据库。每个层次做到高内聚，层与层之间做到低耦合。
图
2 X
轴分层结构
在系统实现过程中，可以综合考虑现状，
X2
应用和
X3
框架可以不分拆，
X4
服务和
X5
核心可以不分拆，待后续时机成熟可以再重构分层，这样变更范围仅在内部。
表
2 X
轴七层架构模型及其定位
分层类型 | 分层名称 | 颜色 | 代号 | 分层定位 |
交互 | 界面层 | 红 | X1 | 界面更像是用户的延伸，而非应用的延伸。界面可被视为用户代理。根据用户喜好、语言、平台（手机、电脑、平板等）开发各种用户界面。 |
业务 | 应用层 | 橙 | X2 | 一个应用可以有多个界面，根据市场需求，开发各种应用，并以接口的方式展现。 |
框架层 | 黄 | X3 | 将常用的应用流程设计成框架，后续开发同类型应用时，只要通过参数或者
DSL
，就可以轻易订制应用，减少开发成本。框架也可以用接口的方式开放让外部调用。 |
领域 | 服务层 | 绿 | X4 | 服务层针对领域对象进行操作，并提供弹性的调用接口。服务层接口通常数目不多，但每个接口通常参数相当多。服务层没有状态，也不做缓存。 |
核心层 | 蓝 | X5 | 核心层反映领域模型，核心层的接口基本就是对此领域模型进行操作。建立领域模型，一方面帮助接口设计，另外一方面帮助数据存储设计，梳理出弹性的存储方式。 |
资源 | 代理层 | 靛 | X6 | 具备下列作用：数据代理，代表外部系统或数据库；缓存，为了效率或提高可用性（当外部系统掉线）；数据模块，支持读写分离；转接或转发，转接到外部系统，转发到日志系统；数据备份系统（通过事件钩子）；热备系统接入。 |
数据层 | 紫 | X7 | 数据是公司最重要的资产。根据数据的特性，数据库可以是：关系式数据库；列数据库；
Associative DB
；
Key-Value
；文件数据库；日志。 |
业务维度（
Y1 ... Yn
）
从业务维度进行划分，按照业务类型对系统进行分类。业务系统的划分更多依赖业务领域的知识，这个维度设计最常用的方法论就是领域驱动设计DDD。
当
Y
轴的一个业务系统需要调用
Y
轴的另外一个业务系统时，兼顾效率和耦合，这套架构设计方法论给出了具体的架构原则：
- 当被调用的是公共系统时，那么调用将被视为内部调用，即服务可以直接调用服务。考虑到公共系统比较稳定，不会经常改变，直接调用可以减少调用环节，保障效率。
- 当被调用的是非公共系统时，那么调用将会被视为外部调用，即通过代理层去调用被调用系统的对外服务接口。这相当于把两个系统后台进行了串联，降低了系统之间的耦合，后续被调用系统发生变更，对调用系统的影响也可以藉由其代理层进行了隔离。
图
3 Y
轴不同业务系统之间调用关系
系统维度（
Z1...Zn
）
该维度主要关注软件、容器、运行时、操作系统、虚拟机、到硬件等这些与业务无关系统的架构。
Z
轴的系统可以分别用于前端优化、应用优化、平台优化、资源优化等层面。
图
4 Z
轴分层结构
时间维度（
T1 … Tn
）
对于一个新产品来说，架构不是一次成型的，从初始到成熟要经过一个不断演进的过程。对于一个已有产品来说，架构的优化也是要结合实际情况分步骤实施。除了技术上的考虑之外，我们还需要考虑市场及投资等方面的情况。
通常，在研发的初期，产品本身的定位还不太清晰，需要快速地迭代投放市场获取先发优势，以及验证想法，不断地明确产品的定位。这个阶段产品需求变动非常频繁，许多架构的驱动因素尚未明确，如果过于关注架构，那产品推向市场就会遥遥无期。随着产品定位的逐步清晰，架构的驱动因素及约束条件都逐渐浮出水面，这个时候架构设计的重要性就显现出来了。另外，我们还需要根据投资预算来调整架构设计。如果投入比较充裕，那我们就可以投入更多的人力来提前将架构驱动因素研究清楚，甚至可以针对不确定的约束提供多套备选方案。
先分享到这里，后续我还会继续分享各个维度的架构设计心得，请感兴趣的小伙伴记得关注哦！
原创不易，如果你觉得有价值，麻烦动动手指点个 「
赞
」，老兵哥会更有动力。另外，我还会持续分享职业规划、应聘面试、技能提升、影响力打造等经验，
关注
「
IT老兵哥
」，
赋能程序人生
！
网站栏目：如何建立架构师的立体化思维？-创新互联
网页链接：
http://cdkjz.cn/article/igcih.html
