编程即设计，代码即架构。
概述###
架构，这个词比较神秘，以致于很多程序员望而却步，以为要什么了不得的本事。
架构的目标是什么呢？代码，实现所需服务；架构，致力于以更小成本、更高质量地实现所需服务。架构，是兼顾质量与成本的魔法。 但架构并不研究如何实现具体服务，—— 它研究的是如何妥善安置那些实现服务的构件，管理依赖、边界和变化。
-
如何将不变从变化中分离出来，沉淀为稳定的组件 ？如何管理组件之间的依赖 ？
-
如何识别组件所在的边界和上下文？ 如何管理各种边界和上下文 ？
-
如何让变化更容易显露和识别 ？ 如何管理多维度的变化 ？
-
如何让业务逻辑变成可配置的易变更的插件 ？
目标###
小问题小设计，大问题大架构。架构听上去高大上，实际上也是为了解决问题的。不过，架构与程序不同，是在不同层次上求解问题。
架构设计是宏观性考量，在整体上理解问题的复杂性，给出方案，并论证方案的可行性，提供一系列准则指导执行。缺乏架构设计而直接着手处理问题，会出现三个严重问题：
-
在遇到实质性难题时，会一筹莫展或反复折腾，一次次返工，耗费大量的人力和成本；
-
缺乏质量的考量，上线后发现无法满足用户的需要；
-
缺乏整体的考虑，在业务发展的时候，原有实现不具扩展性，无法敏捷地支持中期和长远目标。
因此，架构的目标主要有三个：
-
提前识别问题的复杂性和关注点，提供可行的经过论证的解决方案；
-
建立服务质量指标，确定设计方案可以满足指定的质量指标；
-
规划整体设计，提供长远的可扩展性。
要实现架构目标，先要问：要解决的问题是什么？问题的复杂性在哪里？弄清楚目标和靶点，才能一击命中。
衡量###
一个好的架构设计，它起什么作用呢？
-
是不是有针对性地解决了问题固有的复杂性？ 通过提供渐进稳定的领域模型，让问题理解、描述和求解都更清晰自然了；
-
是不是令需求更快地实现，大幅降低了开发成本？ 比如原来要花时间修改代码、测试、发布系统，后续只要新增配置，测试并刷新配置就搞定了；原来需要5人日，现在只需要 2人时；
-
是不是让系统的依赖更清晰了？比如原来你调我我调你，乱成一团，现在能够清晰地看到数据流在各个模块的流通和流向、脉络；
-
是不是更稳定了？比如原来磕磕碰碰，做百次操作就有一次失败，现在做十万次操作才有一次失败；
-
是不是更容易操作了？比如原来需要ABCDE五步操作，现在一键无忧完成；
-
是不是足够有弹性和灵活性，可以支撑数年的业务发展？ 比如原来遇到新业务就要做许多兼容，现在只要配置一些规则、流程就能适应新业务的发展。对新增开放，对修改关闭。
综上所述，架构设计至少有几个方面可以衡量：
-
识别出问题的关键复杂性，建立稳定有效的领域模型。
-
大幅降低开发与维护成本。 可以落定到人力与时间。
-
系统脉络更清晰。可以绘制出系统模块的依赖图，通过依赖图的节点与节点链接数量来判断。
-
更稳定。操作失败、出现各种问题的比率。
-
更容易操作。 操作的步骤数 乘以 操作失败的比率。
-
弹性和灵活性。 支持新业务的难度，以新增代码量和修改代码量来衡量。