您知道什么是应用架构图吗？

一、开篇

我 们在学习新的技术或者解决某些业务和技术问题时，很多同学都会一股脑的钻进细节和思考如何快速解决，久而久之形成了点状的知识结构和认知体系。如同我经常在面试一些中高级程序员的时候，经常会问一个问题：java 的知识体系是什么/java 的组成是什么。也正如自己所预期的那样，经常有候选人不知所云，用我高中一位班主任的口头禅：茫茫然不知其所以然。于是我们得到一个结论：体系的思考和学习是如此的重要，以至于另当今浮躁的社会和风气让那些可以沉下来的程序员无形中少了很多竞争对手。

二、回归主题

我们回归本次的主题，首先了解应用架构图的作用是什么：主要是用来描述应用架构的，具体体现在描述系统的组成和框架。这种解释即清楚又抽象，本文我们着重从应用的维度去了解如何构建我们的应用架构图，以及什么是应用架构图，那到底是什么应用？

百度百科给出了很多种解释，在众多的解释中，给到我比较有启发作用的是数字布鲁姆的信息化工具集合图示中，按照认知领域创造六个层次，分别是识记、领会、应用、分析、评价、创造，其相互之间环环相扣，互相制约且相互依存。在这六大层次中，应用可以说是有着核心地位，有着承上启下和最终价值呈现的作用。

撇开数字布鲁姆理论本身的解释我们可以这么理解，对于某个企业在使用某个领域开展生产活动，通过分析和评价我们得知该领域投入市场发挥的作用和产生的价值，最终决定着企业是否需要通过创新等手段更进一步挖掘其更大的价值然后再给企业带来更高的循环价值，如果采用更为官方或者抽象的语言就是对于企业来说，决定企业的发展战略方向和企业经营的业务模式，对于一个系统来说决定着系统的价值有多大，用户的评价是不是好未来是否还需要将该系统进行更大范围的推广甚至扩大规模，这是向上。

向下的作用，我们理解只有识记、领会之后，才有可能进入应用层次。识记是一个心理学上的词语，它是记忆的一个重要的缓解，通过反复的感知的过程，在达到记忆条件后，开始领会，即领略事务中蕴含的道理并对其深有体会。那我们记忆什么东西，我们去感知去领会什么东西变的尤为重要，而这不难想象，对于一个系统而言完全取决于系统的应用场景事什么，说到底总结下来还是应用二字。

我们来看一下对于应用架构百度百科的解是：

应用架构（Application Architecture）是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次：企业级别的应用架构、单个系统的应用架构......

无论企业级别的应用架构还是单个系统的应用架构，最终都是通过系统功能和技术两个维度来阐述。这个时候就会出现些困惑，我们在学习或者画业务架构图甚至产品架构图的时候，也会出现系统功能的概况性内容，也就是说无论是在以系统功能描述为核心的应用架构，还是在业务架构中都会出现带有业务语言的功能描述字样，例如财务管理、营销管理，这些简化的功能描述短语无论在应用架构还是在业务架构中都会出现，对于初识架构以及开始自己着手画架构的同学来说，难免会出现画着画着四不像的情况，甚至会出现自己画完以后当别人问起，你这个图是那种架构图，于是内心深处本来想说画业务架构画着画着不再是真正意义上的业务架构，那到底该如何真正区分各种架构呢？

我们程序员经常说的系统架构，也就是我们讲的企业架构， TOGAF 做了如下的描述：

• 业务架构：定义业务战略、治理、组织和关键业务流程
• 应用架构：应用之间结构和交互的描述
• 数据架构： 描述组织的逻辑与物理数据资产及数据管理资源的结构
• 技术架构：描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力，包括 IT 基础设施、中间件、网络、通信、处理和标准等

经过 TOGAF 的一系列描述，似乎又冒出一个问题，技术架构和以技术为核心的应用架构的区别又在哪里呢？

所有的疑问和不解的答案归结于两个字：领域。

一直以来我们一直尊崇或者向往的 DDD 领域驱动编程，看似高大上，实则在绝对多数公司是没有真正执行起来的，其原因表面看起来是使用了 DDD 模式进行开发后，整个开发的工作了变的巨大无比，工作了可能双倍不止的增加，而通常业务发展又是及其迅速的，业务的变更和改动也是频繁且没有道理的，于是在软件公司最终从上到下认为 DDD 是个好东西，但是无法执行。而个人认为深层次的原因还是对领域的认识和诸多误解，甚至是不解以及无知而导致的不认同，我们常说业务和技术要有共同的语言，即通过领域模型这种介于业务和技术之间的事务来达到认知一致，没错，道理非常浅显却依旧无法执行。在 DDD 领域驱动编程中，想要真正的执行所有的核心关注点都在领域模型上，一个相对稳定的相对完善的领域模型是如此的重要（至少是在未来相当一段时间内），特别是对 DDD 来说，就现实而言如果连业务自身都没办法稳定或者通过讨论确当一个企业、一个产品、一个项目未来一段时间内可预见性的时间并加以预判，何来稳定的领域模型，何来 DDD 的落地。而业务和产品往往都是暂时这么设计，将来遇到问题再改，当然技术时长也这样，但是技术的暂时设计所带来的影响从 DDD 的落地来说是有兜底方案相对的不会反过来影响业务和产品，而业务和产品的兜底方案是技术按需改代码。

无论是对各种架构图的迷惑还是对 DDD 无法真正落地的简单分析，根本原因还是大家对领域这一概念的模糊，对领域在软件设计、开发过程中加以忽视导致的。大家可以反思一下，在自己过往的编程经历中，有多少是对领域加以重视，那不重视的体现就是接到需求后上来就干，好一点的做一做技术方案然后就开搞，需求有变更再改技术方案最后改代码。

在我的印象中在这方面我们所崇拜的大厂做的确实不错，现在慢慢的很多效益不错的企业也开始注重领域方面的设计，这种设计不仅仅是技术，也设计到了业务和产品，领域边界的确定与不确定波及的不仅仅是技术团队，乃至整个企业的组织架构都会有非常深远的影响。

三、总结

纸上得来终觉浅，绝知此事要躬行。在我们画应用架构图或者其他系统架构图时，我们要首先明白每种架构图的领域边界到底是什么，是为了解决什么业务场景和问题，否则就会出现四不像的情况。于是我们就需要知道领域到底是怎么回事，领域建模、领域驱动这又是一个值得学习、深思、讨论和实际落地的话题。

回到我们的疑问，您知道怎么画应用架构图吗？

• 第一步：通过领域边界搞明白各种系统架构图的边界到底是什么。
• 第二步：自己是真的要花应用架构图吗？是要画以系统功能为核心的应用架构图还是以技术为核心的应用架构图。
• 第三步：定义各个系统或者功能的边界和定义、系统间的关联关系和约束条件，对下依赖什么，对上供谁使用达到什么效果。