本文是架构设计实践五部曲系列文章的第一篇，架构与架构图。本文将对架构作深入的阐释，并教你什么时候画架构图、怎么画架构图。
在日常系统开发过程中，作为技术人员想必大家都参与过架构设计的工作。做过一段系统架构工作之后，心里对于架构产生了越来越多的问题。
为了回答这些问题，我总结了这一系列的文章，沉淀自己对于架构的理解，总结架构设计的实践和思路。希望能帮助到在做架构设计过程中，同样有这些困惑的你。
什么是架构
什么是架构？我们先看一下百科中是如何定义架构的。
在百度百科中的定义是：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
在维基百科中的定义是：软件体系结构是指软件系统的基本结构，创建此类结构的规则以及这些结构的文档。需要这些结构来推断软件系统。每个结构包括软件元素，它们之间的关系，元素和关系的属性，以及每个元素的引入和配置的基本原理。软件系统的体系结构是一种隐喻，类似于建筑物的体系结构。
从百科中我们提炼出一句话，
“架构是一种整体与局部关系的抽象描述”
。这句话还是稍显抽象，不太容易理解。换个角度，按照中文的字面理解，对“架构“两个字进行拆解，就会发现很有意思含义。架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“按照一定的结构连接起来。
下图为古代的木质建筑的结构图：
对应到软件架构，这里面的“木”代表什么，软件架构中的“结构”是什么，这些软件系统的“木”又是如何连接的？
-
关联到软件领域，木就是系统中的要素，我们将他们称之为架构要素。架构要素可以是子系统、模块、应用服务。
-
结构，是架构的产物。不同的软件系统会有不同的结构，这些结构是为解决不同场景而设计的。
-
连接，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。
总结一下架构的本质，即架构 = 要素 + 结构 + 连接，将系统要素按照特定结构进行连接交互。
架构域的分类
在软件设计中架构域是如何划分的，架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构。首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。如何针对当前需求，选择合适的架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。
业务架构
在需求初期，业务的需求描述往往比较模糊，可能只是一句话。他们可能来自老板、运营或者用户。直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。
问题域，是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围。能够帮助我们的产品拥有更高的可拓展性，在后续具备迭代和优化的空间。
在经过问题域的罗列后，我们应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。根据核心需求和问题域的答案，梳理出业务流程。
业务架构就是在业务需求初期，将模糊的需求描述转变成清晰的问题域，梳理出清晰的业务流程。为产品架构提供输入。
业务架构包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。
业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须设计软件架构。试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重建，更不要说直接拿别人的现成架构方案了。例如，A 业务中有套 A 系统，恰巧 B 业务需要解决类似 A 业务的场景。此时很多情况，B 业务的人员会考虑把 A 系统直接拿过来，以为做一些简单的修改，就能在 B 业务中落地。结果在系统落地的过程中，很多功能模块不能直接使用，都要重新按照业务进行修改。最终的结果是，A 系统经过不断的重写修改变成了 B 系统。
上述的案例正是由于业务架构没有做到位，没有做好软件架构的分析和设计，所以我们很难看出两个系统有多少差别，也无法确定用一个业务系统去覆盖另一个业务系统的可行性有多大。相反，对 A 和 B 业务领域进行业务架构梳理，我们就能清楚发现两者的一致与区别，就能有效的评估系统覆盖的可行性和合理性。
经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。
数据架构
企业架构由业务架构驱动，从业务架构分析业务流程、定义数据架构，流程和数据结合定义产品架构。这中间，数据架构起着至关重要的作用。企业 IT 系统的价值并不在于选取的技术有多先进，使用的硬件有多强大。而是企业业务数据的处理和存储。一家公司最宝贵的资产无疑就是–数据。毫无疑问，在当今大数据的时代背景下，缺少数据资产的建设和使用，就失去与同行业争夺竞争的机会。
因此，数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。
系统需要什么样的数据
数据是对客观事物的真实表现，企业业务过程中的所有对象的状况都可以用数据记录下来。业务运营过程中有两条重要的线索：流程和数据。业务流程离不开数据流转，业务运营状况通过数据反映。基于业务架构的端到端的流程建模过程中，会衍生出对应的业务数据对象，需要与数据架构模型对接。流程模型和数据模型对接后落实到应用层面，就形成了产品架构。
数据架构中的数据包含静态数据和动态数据。相对静态部分如元数据、业务对象数据模型、主数据、共享数据。相对动态部分如数据流转、ETL、数据全生命周期管控治理。
如何存储这些数据
数据架构是为了建立一个共享、通用、一致的数据基础平台，解决企业信息孤岛。如何存储业务数据，需要结合自身需求，采取合适的数据分布策略。通常，数据存储的分布策略有两种：一种是集中式存储，一种是分布式存储。
集中式存储就是讲数据集中存放于总部数据中心，所有的下属机构或子公司不放置和维护数据，都想总部数据中心进行访问。
集中式存储
分布式存储就是数据分布存放于总部、分支机构或者子公司，每个分布节点需要维护和管理自己的数据。分布式的数据存储架构中，还需要考虑每个分布式节点的数据与总部节点数据进行同步、备份，做到数据资产的安全、可靠。
分布式存储
如何进行数据架构设计
数据源自于企业的业务流程，从业务流程中我们可以找出领域对象，基于领域对象进行分析，就能得到对象的属性。根据业务关系进而抽取领取对象之间的关系。因此，领域建模是一种对数据架构很有帮助的建模思想。通过领域建模，我们不仅能清晰的反映企业的业务域，还能清晰的描绘出一幅企业的数据模型。
